最稳妥方式是直接使用RegOpenKeyExW和RegQueryValueExW：显式指定类型、两次调用获取缓冲区大小、检查ERROR_SUCCESS、正确处理Unicode路径与WOW64标志，并立即捕获GetLastError()。
用 RegOpenKeyEx 和 RegQueryValueEx 读取注册表字符串值最稳妥
Windows API 提供的原生方式是唯一不依赖第三方库、能精确控制权限和错误处理的方案。别用 SHGetValue 或 CRegKey 封装类——它们在 Unicode/ANSI 混用或远程键（如 HKEY_USERS.DEFAULT）场景下容易静默失败。
关键点：必须显式指定 REG_SZ / REG_DWORD 等类型，不能靠自动推断；缓冲区大小要按字节算（sizeof(WCHAR) 影响宽字符）；返回值必须检查 ERROR_SUCCESS，不能只看指针是否为空。
-
RegOpenKeyEx的samDesired参数建议用KEY_READ，避免因权限不足返回ERROR_ACCESS_DENIED却误判为键不存在 - 读取字符串时，先调用一次
RegQueryValueEx获取所需缓冲区大小（lpcbData输出），再分配内存并二次调用——否则易触发缓冲区溢出或截断 - 对
REG_MULTI_SZ类型，需手动遍历空字符分隔的字符串块，不能直接当 C 字符串用
读取 REG_DWORD 值时，lpData 必须传 DWORD* 地址，不是 DWORD 变量本身
常见错误是写成 RegQueryValueEx(hKey, L"ValueName", ..., &dwValue) 却忘了 dwValue 是栈变量，而 API 要求的是可写入的内存地址。更隐蔽的问题是：如果注册表项实际是 REG_QWORD，但代码硬指定 REG_DWORD 类型，API 会返回 ERROR_MORE_DATA 而非类型不匹配错误，导致逻辑误判。
- 务必先用
RegQueryValueEx的lpType参数获取真实类型，再决定如何解析lpData - 读取
REG_DWORD时，lpcbData必须初始化为sizeof(DWORD)，否则可能因旧值残留导致读取失败 - 64 位程序读取
WOW6432Node下的键需显式加KEY_WOW64_32KEY标志，否则默认访问原生 64 位视图
中文路径或值名含 Unicode 字符时，必须用宽字符 API（RegOpenKeyExW）
哪怕项目设置为“使用 Unicode 字符集”，链接时仍可能默认调用 ANSI 版本（RegOpenKeyExA），导致中文注册表路径被截断或乱码。Visual Studio 默认宏 UNICODE 和 _UNICODE 仅影响头文件声明，不保证链接符号正确。
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南，适用于远程桌面访问、安全 RDP 等。
立即学习“C++免费学习笔记（深入）”；
- 显式调用
RegOpenKeyExW和RegQueryValueExW，避免依赖宏展开 - 字符串字面量一律加前缀
L，例如L"SOFTWARE\MyApp"，否则const char*传给W版本会编译报错 - 若需兼容旧系统（如 Windows XP），注意
RegOpenKeyExW在 NT4 上不可用，但 XP 及以后均支持
读取失败时，GetLastError() 返回的错误码比函数返回值更可靠
RegOpenKeyEx 返回 ERROR_FILE_NOT_FOUND 表示键不存在，ERROR_PATH_NOT_FOUND 表示父键缺失，但两者都可能因权限策略被统一映射为 ERROR_ACCESS_DENIED。此时仅看函数返回值无法区分真实原因。
- 每次 API 调用后立即调用
GetLastError()，不要跨调用保存 -
ERROR_INVALID_HANDLE通常意味着RegOpenKeyEx已失败但未检查返回值，后续操作用了无效句柄 - 调试时可用
FormatMessage将错误码转为可读字符串，但生产环境建议只记录错误码数字——避免本地化字符串干扰日志解析
注册表路径拼接、类型校验、错误码捕获这三步漏掉任何一环，都可能导致程序在特定用户权限或系统配置下静默失败。没有“默认安全”的简写方式。
