go读windows注册表必须用golang.org/x/sys/windows/registry包，因注册表非文件系统路径，os.open无法识别hkey前缀；需注意全大写键名、双反斜杠路径、wow64视图隔离、utf-16编码转换及显式close()防泄漏。
Go 读 Windows 注册表必须用 golang.org/x/sys/windows/registry
标准库 os 和 io 完全不碰注册表——它不是文件系统路径，也不是常规 IPC 接口。想绕过 registry 包直接调 RegOpenKeyEx？行，但得自己写 syscall 封装，纯属重复造轮子且易出错。
常见错误现象：open HKEY_LOCAL_MACHINESOFTWAREMyApp: no such file or Directory —— 这是因为把注册表路径当成本地文件路径用了，os.Open 根本不认识 HKEY_* 前缀。
- 只支持 Windows 平台，跨平台编译会失败（
build constraints自动屏蔽） - 所有键名必须用全大写前缀：
registry.LOCAL_MACHINE，不能写成local_machine或字符串"HKEY_LOCAL_MACHINE" - 权限问题很常见：32 位 Go 程序默认访问的是 Wow6432Node 视图，64 位键可能“看不见”，需显式加
registry.KEY_WOW64_64KEY标志
registry.OpenKey 的 subkey 参数不含根键，且不能以反斜杠开头
这是最容易手抖写错的地方。比如想读 HKEY_LOCAL_MACHINESOFTWAREmicrosoftWindowsCurrentVersion，root 传 registry.LOCAL_MACHINE，subkey 必须是 "SOFTWAREMicrosoftWindowsCurrentVersion"，而不是 "SOFTWARE..." 或 "HKEY_LOCAL_MACHINESOFTWARE..."。
错误示例：registry.OpenKey(registry.LOCAL_MACHINE, "SOFTWARE", registry.READ) → 报 The parameter is incorrect.（错误码 87）
立即学习“go语言免费学习笔记（深入）”；
-
subkey是相对路径，不包含根键名，也不带开头的 - 路径分隔符必须用双反斜杠
（Go 字符串字面量），单会被当转义符处理 - 末尾不能有多余
，否则打开失败（Windows API 层面拒绝非法路径）
读取字符串值优先用 GetStringValue，别手动 decode REG_SZ 字节数组
注册表值类型（REG_SZ、REG_DWORD 等）和 Go 类型不一一对应，GetValue 返回原始 []byte 和类型常量，需要自己判断、转换。但绝大多数配置项是字符串，直接用封装好的方法更稳。
典型翻车点：拿到 REG_SZ 的 []byte 后直接 string(b)，结果末尾多出 或乱码——因为 Windows 用 UTF-16 LE 存储，而 Go 字符串是 UTF-8。
-
GetStringValue内部已做 UTF-16 LE → UTF-8 转换，还自动 trim NULL terminator -
GetIntegerValue专用于REG_DWORD/REG_QWORD，避免字节序和符号位误判 - 如果真要读二进制值（
REG_BINARY），再用GetValue+ 类型判断，别硬套字符串方法
关闭 registry.Key 不是可选项，是内存泄漏触发器
registry.Key 底层是 Windows 的 HKEY 句柄，Go 不会自动 GC。漏掉 Close()，每开一次就占一个内核对象，跑久了直接触发 ERROR_NO_MORE_ITEMS 或句柄耗尽。
最简安全模式：用 defer key.Close()，但注意作用域——如果在循环里反复 OpenKey，defer 会堆积，应配对调用。
- 即使
OpenKey失败返回nil，也别对nil调Close()（会 panic） - 推荐写法：
if key != nil { defer key.Close() } - 某些场景（如只读一次的启动配置），用
registry.GetValue静态函数更省事，它内部自动开/关键，不用管生命周期
事情说清了就结束。注册表操作看着像文件 IO，实则是 Win32 API 的薄封装，路径规则、编码、句柄管理、视图隔离这四点，漏一个就卡住。