第一步是读取HKEY_CLASSES_ROOT\.ext的默认值获取ProgID，再通过HKEY_CLASSES_ROOT\ProgID\shell\open\command查执行路径；需处理AppX、DelegateExecute等现代机制及权限限制。
读取 HKEY_CLASSES_ROOT\
下的 ProgID 是第一步
Windows 注册表里，扩展名到程序的映射不是直连的，而是先查
对应的 ProgID（比如
→
），再通过这个 ProgID 去找默认打开命令。直接读
的默认值就能拿到 ProgID，但要注意：如果该扩展名没被显式注册（比如用户从未改过关联），它可能根本不存在——此时得 fallback 到系统默认逻辑（如
或通用类如
），但这种 fallback 没公开 API，实际中建议先检查是否存在。
时用
，权限只需
ProgID 可能带空格或特殊字符，但注册表里是纯字符串，不用额外转义
某些 UWP 应用注册的 ProgID 会以
开头，这类无法直接执行，需调用
或
从 ProgID 查
默认值获取可执行路径
拿到 ProgID 后，拼出子键路径
，读它的默认值。这个值通常是带引号的路径加参数，例如：
。关键点在于：引号不是装饰，而是必须解析的分隔符；
是占位符，不是真实路径的一部分。
用
读出字符串后，先 trim 首尾空白，再按第一个双引号配对提取可执行路径部分
不要用
或直接
执行整条 command 字符串——参数注入风险高，且
未替换
如果该子键不存在，尝试降级查
（常见于 UWP 或现代应用代理），这时得到的是 CLSID，需进一步处理
能简化流程，但不返回完整路径
WinAPI 提供了
，传入
可直接获取“推荐用于打开该扩展名的程序路径”，但它只返回最简路径（如
），不带盘符和完整目录，也不保证可执行——因为它是从 PATH 或已知安全目录中推导的。实际项目中若需要绝对路径，仍得走注册表查。
C知道
CSDN推出的一款AI技术问答工具
下载
调用前必须用
或手动验证扩展名是否已关联，否则容易返回空或错误结果
在 Windows 7+ 可用，但对自定义协议（如
）或非标准扩展名支持不稳定
它内部也查注册表，只是封装了 ProgID 跳转逻辑，性能差异可忽略，但可控性更低
权限与沙箱环境下的失败很常见
在非管理员进程、UWP 容器、或者启用了 Controlled Folder Access 的机器上，
的部分子键可能被重定向或拒绝访问。典型现象是
返回
或
，即使注册表编辑器里能看见。
立即学习
“
C++免费学习笔记（深入）
”；
不要假设
总是可读——它本质是
和
的合并视图，后者优先级更高，但当前用户无写权限时，合并可能不完整
调试时可用
过滤 RegOpenKey，看具体哪个路径被拒绝或返回空
若目标是给用户展示“默认打开方式”，更稳妥的做法是调用
（仅限本地文件）或
配
获取类名，再反查——虽然绕，但兼容性更好
事情说清了就结束。真正难的不是读注册表，而是面对
、
、
、
这些现代机制时，没有统一路径可走。
.ext.ext.txttxtfileHKEY_CLASSES_ROOT\.extApplications\*.exeGenericFileRegOpenKeyExHKEY_CLASSES_ROOTKEY_QUERY_VALUEAppX...ShellExecuteExActivateApplicationshell\open\commandHKEY_CLASSES_ROOT\ProgID\shell\open\command"C:\Windows\System32\notepad.exe" "%1"%1RegQueryValueExstd::systemCreateProcess%1shell\open\command\DelegateExecuteAssocQueryStringAssocQueryStringASSOCSTR_EXECUTABLEnotepad.exeAssocQueryKeyAssocQueryStringmyapp://HKEY_CLASSES_ROOTRegOpenKeyExERROR_ACCESS_DENIEDERROR_FILE_NOT_FOUNDHKEY_CLASSES_ROOTHKEY_LOCAL_MACHINE\Software\ClassesHKEY_CURRENT_USER\Software\ClassesProcess MonitorFindExecutableShellExecuteExSEE_MASK_CLASSNAMEAppXDelegateExecuteCapabilitiesApplicationAssociationRegistration