这问题挺有意思的——你遇到的情况其实是.NET跨平台兼容设计带来的结果，下面分几个点给你掰扯清楚：

1. 为啥Mac上能正常跑？ #

你用的Microsoft.Win32.Registry这套API，在非Windows平台（比如Mac）上，.NET runtime（Unity适配Mac时用的是Mono或者.NET Core/6+ runtime）给做了模拟实现，不是直接报错甩锅。这个设计就是为了让原本针对Windows写的代码，不用改一行就能在跨平台环境下运行，保持API的一致性。

说白了，你DLL里的注册表操作代码，在Mac上根本没碰Windows注册表（毕竟Mac本来就没这玩意儿），而是被runtime转成了文件系统操作，模拟出注册表的键值对存储逻辑。

2. 数据到底存在哪儿？ #

具体存储位置要看Unity用的.NET runtime版本，但大致跑不出以下范围：

• 你代码里用的是Registry.CurrentUser这个根键，数据会存在当前用户的应用配置目录里：
  • 如果Unity用的是Mono runtime：数据通常藏在 ~/.mono/registry/CurrentUser 目录下，每个注册表子键对应一个文件夹，键值对以类似INI的格式存在文件夹里的文件中；
  • 如果Unity用的是.NET Core/6+ runtime：数据会存在 ~/Library/Application Support/com.microsoft.dotnet/registry/CurrentUser 目录下，结构和Mono的类似，子键对应文件夹，键值对存在文件里；
  • 要是你用IL2CPP编译成Mac应用，Unity会给应用加沙盒，这时候数据会被放到应用专属的沙盒目录，大概路径是 ~/Library/Containers/[你的应用Bundle ID]/Data/Library/...。

想快速确认的话，在你的StorageImpl构造函数里加一行代码：

Debug.Log($"实际存储路径: {key.Name}");

运行后看Unity控制台，就能拿到真实的文件系统路径了。

3. 底层是怎么实现的？ #

非Windows平台上的Microsoft.Win32.Registry实现，本质就是用文件系统模拟注册表的层级结构：

• 注册表根键（比如CurrentUser）对应一个根目录；
• 每个注册表子键对应目录下的一个子文件夹；
• 每个键值对对应子文件夹里的一个单独文件，或者统一存在一个配置文件（比如JSON/INI）里；
• OpenSubKey、CreateSubKey对应创建/访问文件夹；
• GetValue、SetValue对应读/写文件内容；
• Flush操作就是把内存里的数据同步到硬盘上的文件里。

这种模拟完全照搬Windows注册表的API行为，所以你的代码不用改任何地方，就能在Mac上实现数据持久化，只是存储介质从Windows注册表变成了普通文件。

要注意的是，这不是Unity特有的功能，任何基于.NET Standard 2.0的代码，在非Windows平台上运行时，都会触发这个模拟逻辑。

内容的提问来源于stack exchange，提问作者Janko