C# 里读写注册表这件事，说简单也简单，Microsoft.Win32.Registry几个静态类摆在那，OpenSubKey、SetValue、GetValue三下五除二就能跑通；说难也真难，我见过不止一个项目在这上面栽跟头——开发机上是管理员账号，一切正常，装到客户那边的标准用户环境里直接抛异常；32 位进程写完的值，64 位的regedit打开死活看不见；还有把整个软件配置全塞进注册表，卸载时清不干净，留下一堆垃圾键值被人吐槽。这篇就把 C# 读写注册表这一套从 API 骨架、值类型、32/64 位视图、权限控制到真实场景落地，按我实际踩过的顺序捋一遍。适合刚接手桌面工具维护的新手，也适合那些"能跑就行、但一直不踏实"的老手重新校验一遍自己的写法。
1. 为什么在托管代码里还要碰注册表
1.1 注册表解决的到底是哪类持久化问题
先把定位说清楚。注册表本质上是一个分层的键值数据库，Windows 系统和大量桌面软件把它当作"机器级/用户级的配置中心"。它跟我们熟悉的 JSON、ini、SQLite 最大的区别在于作用域：一个 JSON 文件放在程序目录下，谁运行程序谁就读同一份；而注册表天然区分HKEY_CURRENT_USER（当前登录用户）和HKEY_LOCAL_MACHINE（整台机器所有用户），这个区分是操作系统层面强制的，不需要你自己写代码去判断"我现在是哪个用户"。
这个特性带来的好处很实在。举个我实际遇到的情况：某桌面工具项目需要记住每个用户的窗口布局和最近打开的文件列表。如果写在程序目录的配置文件里，多用户共用一台机器时就会互相覆盖，用户 A 调整的布局被用户 B 改掉，然后 A 回来发现全乱了。改成写HKCU\Software\某产品名\Layout，系统自动帮你按用户隔离，一行判断逻辑都不用写。
另一个不可替代的场景是与系统集成。开机自启、文件关联、协议处理器、右键菜单、卸载入口，这些东西的"注册点"就在注册表里，没有第二条路。你可以不喜欢它，但只要你的软件需要被 Windows 认出来，就得按它的规矩来。
代价也很明确：注册表没有事务性保障（虽然有RegistryKey事务 API，但使用限制不少）、没有 schema、没有版本管理、写坏了可能影响系统稳定性。所以我的基本判断是——跟系统集成相关的，必须用注册表；纯业务配置，优先用文件。这条线划清楚，后面很多纠结都不存在了。
1.2 什么情况下我坚决不建议写注册表
有一种写法我见一次劝一次：把整个应用的全部配置项——几十上百个字段——平铺在HKLM\Software\公司名\产品名下面。这么干的问题在于，卸载程序只要漏删一个键，机器上就永久残留；而且HKLM写入需要管理员权限，安装器提权一次还行，运行时频繁写就会不断弹 UAC，用户体验极差。
我的经验分界线是这样的：
| 数据类型 | 推荐位置 | 理由 |
|---|---|---|
| 用户个性化设置（窗口位置、主题、最近列表） | HKCU\Software\产品名 | 无需提权，天然按用户隔离 |
| 机器级共享配置（授权信息、端口、服务地址） | HKLM\Software\产品名 | 安装时写一次，运行期只读 |
| 系统集成项（自启、关联、右键菜单） | HKLM或HKCU对应标准路径 | 必须按系统约定位置写 |
| 大数据量配置（规则表、映射表、缓存） | 文件 / 嵌入式数据库 | 注册表值有大小限制，不适合结构化数据 |
| 敏感凭据 | 系统凭据管理接口 | 注册表明文存储，任何同权限进程可读 |
顺带说一个容易被忽略的点：注册表值单个最大约 1MB（实际可用更小），键层级深度也有限制。把一大坨 JSON 序列化后塞进一个REG_SZ里，短时间能跑，量一上来就会出问题，而且调试时极其痛苦——你在regedit里看到的是一行几百 KB 的字符串，根本没法看。
注意：
HKLM\Software\产品名这个路径下写东西，本质上是在改整台机器的状态。卸载程序必须能准确还原，否则就是在给别人添麻烦。这一点在产品设计阶段就该定死。
2. Registry 那套 API 的骨架先摸清楚
2.1 五个根键与打开方式的差别
C# 里操作注册表用的是Microsoft.Win32命名空间下的Registry和RegistryKey。Registry提供五个静态字段对应五个根键：ClassesRoot（HKCR）、CurrentUser（HKCU）、LocalMachine（HKLM）、Users（HKU）、CurrentConfig（HKCC）。日常用得最多的是前三个，ClassesRoot在做文件关联时会碰，LocalMachine在做系统集成时会碰。
打开子键有两种写法，语义不同，很多人混着用：
// 写法一：静态方法打开，返回只读或可写句柄 using var key = Registry.CurrentUser.OpenSubKey( @"Software\某产品名", writable: true); // 写法二：静态方法创建（不存在则建），默认返回可写句柄 using var key2 = Registry.CurrentUser.CreateSubKey( @"Software\某产品名", RegistryKeyPermissionCheck.ReadWriteSubTree);关键差异在于：OpenSubKey在键不存在时返回null，必须判空；CreateSubKey会一路把缺失的中间层都建出来，不会返回null，但它在权限不足时会直接抛异常。我见过新手写Registry.CurrentUser.OpenSubKey(path).GetValue(...)然后空引用崩溃的——因为用户第一次运行，键根本没建过。
还有个细节：OpenSubKey的writable参数默认是false。如果你只传路径不传true，后面调SetValue会抛UnauthorizedAccessException，而且异常信息不会告诉你"你忘了传 writable"，只会说"不允许所请求的注册表访问权"，很容易让人误以为是权限问题去折腾 UAC。
2.2 RegistryKey 的生命周期与 using 的坑
RegistryKey实现了IDisposable，底层持有一个非托管句柄。不释放的后果不像文件句柄那么立竿见影，但长期运行的服务型程序里，句柄泄漏会累积。规范写法一律用using。
这里有个我踩过的坑值得展开：不要在using块外面持有返回的RegistryKey，也不要缓存RegistryKey实例。曾经有个项目为了"性能优化"，在静态字段里缓存了RegistryKey，结果多个线程同时用它写值，偶尔出现句柄失效异常。正确做法是缓存"路径字符串"，每次操作时重新using打开一次。句柄打开的开销在注册表这个量级上完全可以忽略，盲目缓存反而引入并发风险。
另一个坑是CreateSubKey的返回值。有些人写完CreateSubKey不用using包起来，觉得"反正它会自己关"。它不会。句柄要等 GC 回收，中间如果程序被强制结束，注册表可能处于写入未完全 flush 的状态。
public static void WriteUserSetting(string name, string value) { using var key = Registry.CurrentUser.CreateSubKey( @"Software\某产品名\Settings", writable: true); key.SetValue(name, value, RegistryValueKind.String); }这段代码每次调用都打开一次、写一次、关闭。看起来笨，实际最稳。
2.3 32/64 位视图：最容易翻车的一课
这是我个人认为 C# 操作注册表最大的坑，没有之一。64 位 Windows 上，注册表存在重定向机制：一个 32 位进程访问HKLM\Software\XXX，实际落到了HKLM\Software\WOW6432Node\XXX。你在 32 位程序里写的值，用regedit到HKLM\Software\XXX下看是空的，会让你怀疑人生。
反过来也一样：64 位进程写进HKLM\Software\XXX的值，32 位进程去读，读不到，因为它在看WOW6432Node下面的那份。
解决方式是显式指定视图：
using var baseKey = RegistryKey.OpenBaseKey( RegistryHive.LocalMachine, RegistryView.Registry64); // 或 Registry32 / Default using var subKey = baseKey.OpenSubKey(@"Software\某产品名", writable: true);RegistryView三个取值：Registry64强制看 64 位视图，Registry32强制看 32 位视图（在 64 位系统上会映射到WOW6432Node），Default跟随当前进程位数。在AnyCPU编译且关闭"首选 32 位"的情况下，进程位数取决于运行环境，这就是"我本机好好的、客户那边读不到"的经典成因。
我的实际处理原则是：只要涉及HKLM，一律显式OpenBaseKey加RegistryView，不用Registry.LocalMachine直接开。HKCU在多数情况下重定向影响较小（虽然也存在），但为了代码一致性，我一并这么写。
提示：做 32 位兼容的软件，写
HKLM时最好两个视图都写一份，或者在文档里明确要求安装程序统一处理。曾经有个项目因为只在 32 位视图注册了文件关联，结果 64 位资源管理器根本不认，排查了两天才定位到。
3. 读操作：把值安全地拿出来
3.1 读单个值的稳妥写法
GetValue有三个重载，最常用的是带默认值那个：
object raw = key.GetValue("LastWindowPos", defaultValue: null);返回类型是object，因为注册表值可能是字符串、整数、二进制等。这就带来一个必须处理的问题：类型不确定。如果键不存在且没给默认值，返回null；如果值存在但类型跟你预期不符，GetValue不报错，直接原样返回，等你强转的时候才炸。
我封装读取逻辑时固定三步走：判空键、判空值、安全转换。
public static int ReadInt(RegistryKey root, string subPath, string name, int fallback) { using var key = root.OpenSubKey(subPath, writable: false); if (key is null) return fallback; object raw = key.GetValue(name, null); if (raw is null) return fallback; // 注册表里整数可能以 int 或 long 返回，也可能是字符串 return raw switch { int i => i, long l => (int)l, string s when int.TryParse(s, out var parsed) => parsed, _ => fallback }; }这个switch看似啰嗦，但真的有必要。REG_DWORD读出来通常是int，但某些情况下（比如 64 位程序读某些值）会变成long；手工用regedit改成字符串的情况也不罕见（用户或运维手动改配置）。用模式匹配兜住这几种，比裸Convert.ToInt32稳得多，后者遇到null会抛异常，遇到畸形字符串也抛。
3.2 值类型与装箱：object 背后是什么
RegistryValueKind枚举对应注册表的实际存储类型，理解它才能正确读写：
| 枚举值 | 对应 regedit 类型 | C# 常见类型 | 适用场景 |
|---|---|---|---|
String | REG_SZ | string | 路径、名称、普通文本 |
ExpandString | REG_EXPAND_SZ | string | 含%SystemRoot%这类环境变量的路径 |
MultiString | REG_MULTI_SZ | string[] | 多行列表（如多值环境变量） |
DWord | REG_DWORD | int | 布尔开关、端口号、小整数 |
QWord | REG_QWORD | long | 大数值、时间戳 |
Binary | REG_BINARY | byte[] | 序列化数据、加密块 |
None | 未指定 | - | 表示"不指定类型，由系统推断" |
有个细节值得单独说：ExpandString。如果你写的是%ProgramFiles%\某产品名\app.exe，必须用这个类型，系统在读取展开时才会把环境变量替换掉。如果用String存，读出来就是带百分号的原始字符串，拿去启动进程必然失败。这个坑在做开机自启路径时极其常见——用户自定义安装到非系统盘，硬编码路径就废了，正确的做法是存ExpandString并用%ProgramFiles%之类的变量。
SetValue的第三个参数如果传RegistryValueKind.Unknown（或干脆不传），系统会根据值类型自动推断。我不建议依赖自动推断，理由很简单：同样的"1"字符串和整数1，推断结果不一致，跨版本、跨机器可能表现不同。显式指定类型是唯一可靠的做法。
3.3 枚举子键与批量遍历
需要列出某个键下所有子键或所有值时：
using var key = Registry.CurrentUser.OpenSubKey(@"Software\某产品名\Profiles"); if (key is not null) { foreach (string subName in key.GetSubKeyNames()) { using var sub = key.OpenSubKey(subName); string label = sub?.GetValue("Label") as string ?? "(未命名)"; Console.WriteLine($"{subName} -> {label}"); } }两个实测细节。第一，GetSubKeyNames()返回的是相对名称，不包含父路径，拼完整路径要自己加，别指望它给你全路径。第二，GetValueNames()在读HKLM时会因为权限问题对某些系统键抛异常（比如某些受保护项），遍历系统键之前务必try/catch包住单个键的访问，别让一个失败项打断整个循环。
我做配置迁移工具时，遍历逻辑是这么组织的：先GetSubKeyNames()拿到名称列表（这一步很少失败），再对每个名称单独OpenSubKey并用try/catch包裹。这样即使某一项没权限，其余项照样处理完，最后汇总哪些跳过。
4. 写操作：从建键到落盘
4.1 创建子键与写入值
写入的完整动作是"建键 + 设值"。CreateSubKey会自动补全中间层级，所以不需要逐层创建。
using var key = Registry.CurrentUser.CreateSubKey( @"Software\某产品名\Settings", writable: true); key.SetValue("Theme", "Dark", RegistryValueKind.String); key.SetValue("MaxRecent", 10, RegistryValueKind.DWord); key.SetValue("InstallPath", @"%ProgramFiles%\某产品名", RegistryValueKind.ExpandString); key.SetValue("Modules", new[] { "core", "report", "export" }, RegistryValueKind.MultiString);写到这儿有个必须提醒的点：SetValue是覆盖式的，同名值会被直接替换，不做合并。写入前如果关心原值，先GetValue读一次。
另一个实际经验：写完立刻调用key.Flush()。正常情况下系统会延迟刷盘，进程正常退出时也会刷。但如果程序可能被任务管理器强杀、或者写完后马上重启机器，不 flush 就有丢数据的可能。Flush的开销不算小（一次磁盘写），所以只在你确认"这次写入很重要，后续可能立刻断电或强杀"的场景加。配置文件那种每秒写十几次的，绝对不能加。
4.2 删除与清理的策略
删除分三个层次，别搞混：
// 删单个值 key.DeleteValue("Theme", throwOnMissingValue: false); // 删整个子键（含所有子项） key.DeleteSubKeyTree(@"Software\某产品名\Profiles", throwOnMissingSubKey: false);DeleteSubKey只能删空键，如果键下面还有子键会抛ArgumentException——这个设计很多人都不知道，用的时候踩坑。要连子项一起删必须用DeleteSubKeyTree。
throwOnMissingValue和throwOnMissingSubKey这两个参数我建议一律传false。理由：卸载/重置逻辑的语义是"确保它不存在",而不是"确保它存在且被我删掉"。如果值本来就没有，抛异常只会让清理流程半途而废,反而留下更多垃圾。传 false 是幂等的，跑多少次结果一致。
还有一个不能删的东西：HKLM\Software\Classes下面的项，有些是系统共享的。如果你的产品在Classes下注册了扩展名关联，卸载时只能删自己那几项，不能删整个扩展名键（可能别的软件也在用同一个扩展名）。这条我在实际维护中反复强调，因为删错了会影响别的软件正常工作。
4.3 事务写入与回滚
从 .NET Framework 4.0 起，RegistryKey支持事务，用Transaction对象包裹多个写操作，全成功或全回滚。这个特性在做"配置批量迁移"时很有价值——比如从旧版本布局迁移到新布局，中途失败不能留下半迁移状态。
using var tx = Transaction.Create(); using var root = Registry.CurrentUser.OpenSubKey( @"Software\某产品名", writable: true); using (var sub = root.CreateSubKey("Settings", writable: true, tx: tx)) { sub.SetValue("Version", 2, RegistryValueKind.DWord); } // 全部写完后提交，异常时未 Commit 则自动回滚 tx.Commit();需要明确的是它的限制：事务只对同一个HKEY下的操作有效，跨根键（比如同时写 HKCU 和 HKLM）不在一个事务里；另外它依赖底层的 KTM（内核事务管理器），在部分精简系统或特殊环境下可能不可用。所以我的用法是：能用则用，但代码里必须同时准备好"失败后手动回滚"的补偿逻辑，不能把正确性完全押在事务上。
对大多数应用来说，事务属于"锦上添花"。如果你的迁移逻辑足够简单——先写入新路径、校验通过、再删旧的——那么手动两步走反而更透明可控。
5. 权限与安全：为什么你的代码在别人机器上炸了
5.1 HKCU 与 HKLM 的权限差异
这是新手最容易忽略的一点。开发机上通常是管理员账号，而且是 UAC 提权状态，写HKLM一点问题没有。到了客户环境，用户是标准用户，CreateSubKey到HKLM直接UnauthorizedAccessException，同一份二进制行为完全不同。
权限层面的规律：
| 位置 | 标准用户默认可写 | 典型用途 |
|---|---|---|
HKCU\Software\... | 可以 | 用户级配置，首选 |
HKLM\Software\... | 不可以 | 机器级配置，安装时由提权进程写 |
HKLM\Software\Classes\... | 不可以 | 文件关联，安装时写 |
HKLM\SYSTEM\... | 不可以 | 系统级，普通应用不要碰 |
我的处理原则是运行时只写HKCU，HKLM的写入全部下放到安装程序。安装程序本来就是提权跑的，写一次就够，运行期只读HKLM（读通常不需要管理员权限）。这样一来，日常功能完全不受 UAC 影响，不会出现"点个保存按钮弹一次提权框"的糟糕体验。
如果确实需要在运行时写HKLM，那就在应用清单里声明requestedExecutionLevel，让整个进程以管理员身份运行。但这意味着每次启动都要过 UAC，且程序无法被普通用户双击直接使用。这是产品层面的取舍，不是技术问题。
5.2 精细 ACL：给特定用户或组授权
少数场景下需要给HKLM的某个特定键授权，让标准用户也能写。做法是操作注册表键的安全描述符：
using var key = Registry.LocalMachine.CreateSubKey( @"Software\某产品名\SharedState", writable: true); var sec = key.GetAccessControl(); sec.AddAccessRule(new RegistryAccessRule( new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null), RegistryRights.SetValue | RegistryRights.QueryValues, InheritanceFlags.None, PropagationFlags.None, AccessControlType.Allow)); key.SetAccessControl(sec);这段代码把某个具体键的"设值和读值"权限授予本机所有用户。比起把整个HKLM\Software放开，这种最小授权安全得多。
但要提醒一句：这段代码本身需要管理员权限执行（改别人的 ACL 得有权限），所以它只能放在安装程序里，不能放在运行期。而且一旦授予了写权限，就意味着任何进程都能改这个值，不能在这里放任何安全相关的判定依据（比如"是否已授权"这类标志位）。这条是我在代码审查中一定会问的问题：把授权标志放注册表且对普通用户可写，等于把门锁拆了。
6. 真实场景落地：三个可抄的模板
6.1 开机自启与卸载时的对称清理
开机自启的标准位置是HKCU\Software\Microsoft\Windows\CurrentVersion\Run（当前用户）或HKLM对应路径（所有用户）。HKCU版本不需要管理员权限，这是首选。
private const string RunKeyPath = @"Software\Microsoft\Windows\CurrentVersion\Run"; private const string AppId = "某产品名"; public static void EnableAutoStart(string exePath) { using var key = Registry.CurrentUser.CreateSubKey(RunKeyPath, writable: true); // 用 ExpandString 保存，避免安装路径变化后失效 key.SetValue(AppId, $"\"{exePath}\"", RegistryValueKind.String); key.Flush(); } public static void DisableAutoStart() { using var key = Registry.CurrentUser.OpenSubKey(RunKeyPath, writable: true); if (key is null) return; key.DeleteValue(AppId, throwOnMissingValue: false); }几个必须注意的点。第一，路径一定要加引号。如果程序装在含空格的目录（比如C:\Program Files），不加引号系统会解析错，启动失败，而且日志里什么都不会留。第二，值名用固定的产品 ID，不要用可变字符串，否则关不掉。第三，卸载程序必须调用DisableAutoStart——这是"对称清理"的底线，自启项是残留里最招人烦的一类，因为它会导致卸载后每次开机都弹一次"找不到文件"的报错。
我见过一个反面案例：某工具把自启项名写成了带版本号的字符串，升级后旧版本项没删，新版又写一条，用户开机被启动两次。教训就是值名必须是稳定的产品标识，与版本解耦。
6.2 文件关联：按标准流程注册
文件关联涉及多个键，缺一不可。以注册.myext扩展名为例：
public static void RegisterFileAssociation(string exePath) { // 1. 扩展名 -> ProgID 的映射（用户级） using (var ext = Registry.CurrentUser.CreateSubKey( @"Software\Classes\.myext", writable: true)) { ext.SetValue(null, "某产品名.Document", RegistryValueKind.String); } // 2. ProgID 定义 string progIdPath = @"Software\Classes\某产品名.Document"; using (var prog = Registry.CurrentUser.CreateSubKey(progIdPath, writable: true)) { prog.SetValue(null, "某产品名 文档", RegistryValueKind.String); using var icon = prog.CreateSubKey("DefaultIcon", writable: true); icon.SetValue(null, $"\"{exePath}\",0", RegistryValueKind.String); using var cmd = prog.CreateSubKey(@"shell\open\command", writable: true); cmd.SetValue(null, $"\"{exePath}\" \"%1\"", RegistryValueKind.String); } }这段有三个专业细节。SetValue的第一个参数传null表示设置"默认值"，在regedit里显示为"(默认)"那一行，很多关联失效就是因为写到了一个命名值上而不是默认值。DefaultIcon的值格式是"路径",索引，逗号和索引都不能省。命令里的%1是菜单位置参数，表示被打开的文件路径，必须加引号，否则含空格的路径会被拆成多个参数。
另外要注意，用户级关联（HKCU\Software\Classes）优先级高于机器级，而且不需要提权，所以优先走用户级。但用户级关联有个限制：在资源管理器里手动"选择默认程序"时，可能会覆盖掉你写的设置——这是操作系统的正常行为，不建议用代码去对抗它，正确的做法是在软件设置里提供"重新注册"按钮。
6.3 配置持久化：注册表与文件方案的对比
这个场景最能体现选型判断力。我把几种方案在实际项目里的表现列一下：
| 方案 | 写入速度 | 多用户隔离 | 卸载清理 | 可读性/可调试 | 适用规模 |
|---|---|---|---|---|---|
| 注册表 | 快（毫秒级） | 自动 | 需专门写清理代码 | 差（需 regedit） | 小配置，几十个键值 |
| JSON 文件 | 中 | 需自己按用户分目录 | 删目录即可 | 好（直接打开看） | 中大型，任意结构 |
| ini 文件 | 中 | 需自己分目录 | 删文件 | 好 | 简单键值对 |
| 嵌入式数据库 | 快 | 需自己分目录 | 删文件 | 一般（需工具） | 大量结构化数据 |
我的实际分界线：注册表只放"需要跟系统或用户环境绑定"的少量键值，超过 30 个配置项就换文件。这条线不是拍脑袋的，而是基于可维护性——一个塞了 200 个键值的注册表分支，想迁移一次配置几乎没法做，而一个 JSON 文件改个 schema 加个默认值处理就完事了。
还有个务实的好处：文件配置出问题时，用户能自己打开看一眼、改回来；注册表出问题时，用户只能重装。从支持成本角度，文件方案明显更友好。
7. 常见问题速查与排查手法
7.1 异常对照表
这些异常我基本都在真实项目里遇到过，整理成表方便对号入座：
| 异常 | 最常见原因 | 处理方式 |
|---|---|---|
NullReferenceException | OpenSubKey返回null未判空 | 首次运行先CreateSubKey，读取前判空 |
UnauthorizedAccessException | 对HKLM写入但未提权；或OpenSubKey未传writable: true | 改到HKCU，或由安装程序提权写入 |
SecurityException | 受限环境（如部分受管终端）禁止访问注册表 | 捕获后用文件方案降级 |
ArgumentException | 用DeleteSubKey删非空键 | 改用DeleteSubKeyTree |
| 值读不到（不报错） | 32/64 位视图不一致；键名有前导/尾随空格 | 显式OpenBaseKey指定视图，检查键名 |
IOException | 键被标记为待删除，或事务冲突 | 检查是否有DeleteSubKeyTree未完成 |
7.2 排查工具与手法
第一手工具肯定是regedit。但用的时候有个细节：regedit本身在 64 位系统上默认看 64 位视图，如果怀疑是视图问题，需要看WOW6432Node分支下面。另一个常用的命令行方式是reg query "路径" /s递归列出，方便把整棵树导出对照。
写代码时我最常用的排查手法是在关键点把实际访问的完整路径打出来。因为视图重定向的原因，你代码里写的路径和实际落盘路径可能不一致，只靠猜会浪费大量时间。日志里打印key.Name（返回的是完整路径）就能一眼看出真实位置，key.Name在调试视图问题时特别有用。
还有一招：写完值后立刻用GetValue读回来比对。如果读回来跟你写的不一致，说明类型或视图有问题，当场就能发现，而不是等用户反馈"配置不生效"。
7.3 几条用血换来的避坑经验
键名不要用中文或特殊字符。虽然注册表支持 Unicode，但某些工具链、脚本调用对非 ASCII 键名处理不一致，跨语言调用时容易出乱码。产品名部分用英文加版本号，显示名称用值来存。
不要跨线程共用同一个RegistryKey。句柄不是线程安全的，多线程写同一个键请各自using打开。这个坑在长时间运行的后台服务里尤其隐蔽，可能跑一周才偶发一次。
卸载清理写成"幂等 + 白名单"。清理逻辑只删自己在白名单里列出的键和值，不碰任何多余的项。永远不要写"把Software\某产品名整个删掉"之外的递归删除，更不要对不认识的键动手。
避免高频写注册表。有些程序把窗口位置每移动一次就写一次注册表，鼠标拖动时一秒写几十次。正确做法是关闭窗口时写一次，或者加 500ms 防抖。注册表写入虽然快，但频繁小写入对系统日志和磁盘都不友好。
在受管环境里做降级路径。某些企业终端或受限容器环境会禁掉注册表访问（尤其是HKLM），这类环境里try/catch出异常后降级到用户目录下的配置文件，能显著减少支持工单。我在实际维护中吃过这个亏，后来所有注册表访问都统一走一层封装，里面带降级逻辑，上层业务代码完全无感知。
测一遍标准用户环境再交付。这条最朴素也最有效。开发机用管理员账号验证完，再新建一个普通用户账号跑一遍核心流程，HKLM写入、自启、文件关联这些功能一次性全暴露。
最后分享一个我在实际封装里的做法：把所有注册表操作收进一个静态工具类，统一做三件事——显式指定视图、统一try/catch加降级、统一日志记录实际访问路径。业务代码里不再出现任何Registry.调用。这套封装用了几年，后面接手的同事上手成本明显低，出问题时看日志基本能直接定位到是视图、权限还是类型的问题。
