双击打不开文件默认应用被抢回怎么办？文件关联三层记录与打开方式残留项实测清理

双击一个 .md 或 .pdf，弹出来的不是你想用的那个软件；换一次软件打开，过两天又自己跳回去；右键"打开方式"里还躺着一排点不动的老图标。这三件事是同一条链子上的三个环节。微软在讲"打开方式"对话框的文档里把机制写得很直白："By default, any application registered as a subkey of HKEY_CLASSES_ROOT\Applications is presented in the Open with dialog box. These applications are presented in Open with regardless of whether the application is registered to handle the file type."——只要一个程序在 Applications 这个名下登过记，系统就把它列进"打开方式"，跟它能不能处理这类文件无关；程序被卸载而登记没清掉，列表里就只剩下一个点不开的名字。本文把这条链子拆开：谁决定双击、三份记录里哪一份说了算、"打开方式"的残留项到底能不能删。

信息核验时点：2026-11-02（Windows 11 当前正式版 26H2，正式版于 2026-09-29 推出，最新内部版本 26300.9818；文中读取文件关联的命令、三处注册表记录的逐条对照结果、一次"以标准用户身份用 assoc 改关联"的失败实验，以及本机 68 条"打开方式"条目能否定位到实际程序的核对，均在 Windows 10 专业版 19045.6466 的实机上执行并留存输出；引用的微软文档页面均标注了更新时间）

双击一个文件时，Windows 到底按什么顺序找程序？

先给能独立成立的定义：文件关联是注册表里把"扩展名 → 程序类型 → 具体命令"串起来的那组登记。微软在 How File Associations Work（2021-01-07 更新）里逐字列了它管的范围："File associations control the following functionality: Which application launches when a user double-clicks a file. / Which icon appears for a file by default. / How the file type appears when viewed in Windows Explorer. / Which commands appear in a file's shortcut menu."——注意第一项之外还有图标和右键命令，这就是关联写坏时"图标也跟着变"的原因。

找到 ProgID（程序类型标识，注册表里给一类文件起的名字，比如 txtfile）只是中间一步，最后还要落到一条可执行的命令上：HKCR 下这个 ProgID 的 shell\open\command 里那个字符串。本机 .txt 走的就是机器级那条路（HKLM\SOFTWARE\Classes.txt 默认值 txtfile，HKCU 里同名的键不存在），而 txtfile\shell\open\command 的值是 %SystemRoot%\system32\NOTEPAD.EXE %1。如果那条命令写的是全路径，事情就简单了；如果只写了一个 exe 文件名，系统得自己去找这个文件在哪。Application Registration（2021-08-19 更新）给的搜索顺序是逐字这几条："The current working directory. / The Windows directory only (no subdirectories are searched). / The Windows\System32 directory. / Directories listed in the PATH environment variable. / Recommended: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths"。同一页还补了一句只装给当前用户的程序登记在哪："An application that is installed for per user can be registered under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths"。

这条顺序表是理解本文后半部分的关键："打开方式"里一个只有文件名的条目能不能点开，取决于那个 exe 现在还能不能被这五条路找到。装在 D:\某工具\ 里、没写 App Paths、也不在 PATH 里的软件，列表里看得见、点下去没反应；反过来，被搬走过位置的程序，只要还落在 PATH 覆盖的目录里就照样能开。

本站另一篇 Windows 文件资源管理器效率指南：那些被忽略但极好用的操作怎么用 讲过怎么把扩展名显示出来，本文只处理"关联本身错了怎么查、怎么修"。

同一个扩展名为什么有三份记录，哪一份说了算？

三层记录的位置、作用范围和写入时机，用一张表说清：

"用户级优先"不是经验推断，是 HKEY_CLASSES_ROOT Key（2021-01-07 更新）写明的："The user-specific settings have priority over the default settings. For example, the default setting might specify a particular application to handle .doc files. But a user can override this setting by specifying a different application in the registry." 同一页还解释了那个平时在注册表编辑器里看到的 HKEY_CLASSES_ROOT 并不是第三个存放处，而是一个合并视图："The HKEY_CLASSES_ROOT key provides a view of the registry that merges the information from these two sources."

合并视图这一点，本机量出来的数是：HKCR 下以点号开头的子键共 711 个，其中 249 个来自 HKCU\Software\Classes，462 个只在 HKLM 那边存在。也就是说这台电脑上有三分之一的扩展名登记，其实只属于当前这一个用户。

写入位置同样被这一页规定死了，而且和很多人的直觉相反："If you write keys to a key under HKEY_CLASSES_ROOT, the system stores the information under HKEY_LOCAL_MACHINE\Software\Classes. If you write values to a key under HKEY_CLASSES_ROOT, and the key already exists under HKEY_CURRENT_USER\Software\Classes, the system will store the information there instead of under HKEY_LOCAL_MACHINE\Software\Classes." 本机做了对照实验：先在 HKCU 里已经存在的测试扩展名上执行 reg add "HKCR\.qtest57" /ve /d WrittenViaHKCR /f，命令返回成功，值确实落在了 HKCU\Software\Classes.qtest57 上，HKLM 那边没被碰；换一个 HKCU 里从没出现过的新扩展名走同一条命令（reg add "HKCR\.zzq57c" ...），直接返回"错误: 拒绝访问"——因为这条路要写 HKLM，而当前登录的是标准用户。

怎么查出某个扩展名在你电脑上到底归谁？

不用装工具，reg.exe 在 PowerShell 和 cmd 里都能直接跑，四条命令把三层全看一遍（把 .md 换成你的扩展名）：

reg query "HKCR\.md" /ve
reg query "HKLM\SOFTWARE\Classes\.md" /ve
reg query "HKCU\Software\Classes\.md" /ve
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.md" /s

前三条分别读合并视图、机器级、用户级；第四条把这一层的所有子键（UserChoice、OpenWithList、OpenWithProgids）整个倒出来。本机 .md 的实际结果是这样：HKLM 那条报"找不到"，HKCU 的默认值是 md_auto_file，而 FileExts 下的 UserChoice 指向 Applications\Notepad4.exe——三层里最后这份才是双击时真正生效的。这三层互相不一致，在装了第三方编辑器的那类机器上恰恰是常态。

看到 ProgID 还没完，要顺着它找到命令才算闭环：

reg query "HKCR\md_auto_file\shell\open\command" /ve
reg query "HKCR\md_auto_file\DefaultIcon" /ve

第一条给出"实际执行什么"，第二条给出"图标从哪个文件的第几个资源取"。本机第一条查出来是 %SystemRoot%\system32\NOTEPAD.EXE %1——md_auto_file 是系统在你临时选过一次记事本之后自动生成的那种登记，它连默认友好名都没有（这个键存在，但默认值为空），DefaultIcon 这条子键也不存在，这就是"改了关联图标却不跟着变"的一个常见原因。如果第一条直接查不到、返回"找不到"，说明 ProgID 本身在、但它的 open 命令被删掉了，症状正是双击时弹"你想用什么方式打开此文件"或者报找不到程序。

要一次看多个扩展名，把这四行存成一个 .cmd 文件、把扩展名当参数传进去比手工敲快得多；批量脚本的写法本站在 PowerShell 脚本入门：IT 管理员必备的 5 个自动化脚本 里讲过。

assoc 和 ftype 报的"没有找到文件关联"，为什么不能全信？

这两个是最常被教程推荐的命令，但它们各有一个限制，而且限制正好落在最要命的那一层上。

先看微软自己的说明。assoc（2026-09-08 更新，适用列表包含 Windows 11、Windows 10 与 Server 2025）逐字写着三件重要的事："If used without parameters, assoc displays a list of all the current file name extension associations."；"This command is only supported within cmd.exe and is not available from PowerShell. Though you can use cmd /c assoc as a workaround."；以及最容易被忽略的一句——"To make changes in associations, you need administrator privileges."

第三条在本机有非常直接的证据。以标准用户身份执行 cmd /c assoc .qtest57=qtest57.ProgID.1，返回码 5，屏幕上是"拒绝访问。 处理: .qtest57 时出错。"，随后 HKLM 和 HKCU 两边都没有多出这个键——失败是真的失败。更坑的是删除那一步：文档写的是"To remove the file type association for a file name extension, type the extension and an equal sign with nothing after it, for example assoc .ext="，本机照着执行 cmd /c assoc .qtest57=，返回码 2、屏幕上一个字都不打，原来写在 HKCU 的那个默认值纹丝不动。也就是说在非管理员窗口里，assoc 的"改"会明确报错，"删"却可能是无声无息地什么都不做。

第一条限制导致的是另一类误判。assoc 那张"所有当前扩展名关联"的表，本机跑出来是 346 行，里面 .txt 在、.html 在，但 .md 不在——而上一节刚证明 .md 在 HKCU\Software\Classes 里有登记、HKCR 合并视图也能查到。把 HKCU 独有、HKLM 没有的那 98 个扩展名逐个拿去和这张表比对，结果是 0 命中。换句话说：只要一个扩展名的关联只登记在当前用户下，assoc 就当它不存在。同样地，ftype 不带参数在机器的 423 行输出里也找不到 md_auto_file。所以"assoc 说没有关联"只能推出"机器级没有"，推不出"这个扩展名在你电脑上没有默认程序"。

ftype（2023-02-03 更新）管的是 ProgID 那一头的开放命令，它的删除写法是本机那个"半清理"现场的标准成因："To delete the open command string for a file type called example, type: ftype example="。本机给一个只建了 ProgID、没写 shell\open\command 的键执行 cmd /c ftype qtest57.ProgID.1，返回码 2，提示"没有找到文件类型 'qtest57.ProgID.1' 或与其相关的开放式命令。"—— ProgID 明明存在，ftype 却说找不到，因为 ftype 找的是那条命令而不是那个键。

命令只看得到一半、改东西还要管理员权限，那它们还剩什么用？答案是排查机器级默认和 ProgID 命令串。顺便记住 ftype 的参数替换规则，很多"路径带空格就打开失败"的锅在这里：文档给的替换表逐字是 %0 或 %1 对应"要启动的文件名"、%* 对应"所有参数"、%2、%3 依此类推，%~<n> 则是文档原话 "Gets all of the remaining parameters starting with the n th parameter, where n can be any number from 2 to 9."

「打开方式」里那些点不动的残留项是哪来的，能删吗？

先看列表是怎么凑齐的。除了上一节引用的那句"HKCR\Applications 下的程序一律列出"，Specifying File Handlers for File Name Extensions（2025-06-13 更新）说明另一半来源："You can register different applications to open an extension by setting the OpenWithList key for the file extension in HKEY_CLASSES_ROOT. The applications listed under this key for a file extension appear under the Recommended Programs heading in the Open With dialog box." 同一个键在用户侧还记着顺序：本机 .html 的 OpenWithList 里，值名是 a、b、c，数据分别是 msedge.exe、NOTEPAD.EXE、chrome.exe，另有一个 MRUList 值是 cba——列表顺序由 MRUList 决定，跟字母序无关。

而这一份"最近使用"列表存的是裸文件名，微软对此的解释很直白（How to Include an Application in the Open With Dialog Box）："OpenWithList is intended only for legacy apps (must be .exe only) on operating systems prior to Windows XP."，同一页还给了推荐写法："The OpenWithProgids subkey is preferred to OpenWithList to identify an application." 存文件名而不存路径，就是残留项的定义本身：程序搬走了、卸载了、或者压根没登记 App Paths，名字照样留在列表里。

本机的量法是这样：HKCU 的 FileExts 下共有 327 个扩展名有记录，用户级 OpenWithList 条目合计 68 条，其中 48 条能顺着 HKCR\Applications 或 HKCU\Software\Classes\Applications 找到对应的登记，20 条找不到。但这 20 条不能一概叫"残留"，它分成性质完全不同的两类：

也就是说，把磁盘扫一遍（本机限定在 Program Files、两个 AppData 目录和 D 盘，深度三层）之后，20 条里真正"程序已经不在了"的只有两条。判断"是不是垃圾"的正确依据是程序在不在，而不是它在注册表里查不查得到。

还有第三种看着可疑、其实不该动的形态：值以一个大括号包起来的 CLSID 开头。本机这类条目共 11 条，最常见的一种写法是 {1AC14E77-02E7-4E5D-B744-2EB1AE5198B7}\OpenWith.exe，出现在 .dat、.json、.md、.php 等扩展名上；另一条 {F38BF404-1D43-42F2-9305-67DE0B28FC23}\regedit.exe 挂在 .reg 上。这两个 GUID 在 HKCR\CLSID 下都查不到，但在 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FolderDescriptions 里各有登记，名字分别叫 System 和 Windows——这是"已知文件夹"的写法，展开就是 C:\Windows\System32 与 C:\Windows，本机那个 OpenWith.exe 确实在 System32 里（126,144 字节）。所以这些条目指向的是"打开方式"选择器程序和系统自带的 regedit，不是残留。

要清掉真正的残留，微软在 How to Exclude an Application from the Open With Dialog Box 给了两个正规开关。第一个是空字符串值的 NoOpenWith："Applications can disable this tracking by specifying a NoOpenWith value under the application's subkey."，写法是 HKCR\Applications\MyProgram.exe 下面加一个 NoOpenWith。第二个是 SupportedTypes，把能打开的扩展名逐个列出来。这一页同时写了两条限制，值得抄下来："If an application has registered itself in the OpenWithList or OpenWithProgIDs for the file type, it will appear in the Recommended Programs list even if the NoOpenWith entry is set."，以及 "The NoOpenWith entry overrides the SupportedTypes subkey and hides the application in the Open with dialog box."——前者意味着只加 NoOpenWith 清不掉已经写进 OpenWithList 的名字，后者意味着两个开关同时存在时以 NoOpenWith 为准。本机 HKCR\Applications 下 83 个子键里 62 个带 NoOpenWith，说明这条路径被大量程序用过。

只针对某一个扩展名清理，最省事的是删掉这一条用户级列表，让系统重新按推荐生成：

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.iso\OpenWithList"
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.iso\OpenWithList" /f

这里有个顺序规矩必须提前知道，否则会在"删不掉"里绕圈：Windows 不允许删掉还有子键的键。本机用脚本试过先删父键、子键还在的写法，直接返回拒绝访问（winerror 5），必须自下而上：先 shell\open\command，再 shell\open，再 shell，最后才是 ProgID 本身。很多教程里"删了注册表反而更乱"就是这么来的——删了一半，留下一个能查到名字、但 open 命令已不存在的 ProgID，对应症状正是前面那句"没有找到文件类型……或与其相关的开放式命令"。

顺带说清一个反例：HKCU\Software\Classes\Applications 下本机有 3 个程序名，只有 Notepad4.exe 带着完整的 open 命令，另外两个是空的（既没有子键也没有值）。这种空壳登记就是"列表里看得见、点下去没反应"的另一种来源，处理方式是确认程序确实不在了再删这个子键，删之前先导出留底。

默认应用改完又被抢回去，是谁在动？

最常见的一种不是玄学，是软件更新，微软在 双击 .msg 文件会打开意外的版本 Outlook 里逐字给过原因："如果你对早期版本的 Office 执行软件更新或修复早期版本的 Office，则计算机上的文件关联可能会重置为该特定版本的 Office。"，并附上了当时的键值长什么样：键 HKEY_CLASSES_ROOT\.msg，默认值 Outlook.File.msg.14。同页给的解决方法也是官方口径的标准动作——"右键单击扩展名为 .msg 的任何文件，指向 '打开方式'，然后单击'选择其他应用'"、"单击以启用 '始终使用此应用程序打开.msg文件'选项，然后单击 '确定'"。

第二类是升级系统。部署文档 Export or Import Default Application Associations（2021-08-26 更新）的 Tip 4 写的是："On upgrade, Windows may re-assign default handlers for some inbox applications specified in your xml file."，并指向 OEMDefaultAssociations.xml 里的 ApplyOnUpgrade 与 overwriteIfProgIdIs 两个属性。

第三类容易被误会成"被抢"，其实是设计变了。Windows 10 起，程序不再能自己弹框问你要不要设默认。微软当时的产品博客（Windows 10 构建 10122，2015-05-20）逐字写着："With Windows 10, all apps – both Classic Windows apps and Universal Windows apps – will be unable to invoke a prompt to change your defaults, only Windows."，以及那个提示出现的时机："if you install a new photo editor and go into File Explorer and double-click to open a JPG file – Windows will show you a prompt to change your default to the new app. So the prompt is shown in context when it matters, not randomly during setup or when an app is launched." 同一页还预告了过渡期："We have had to do some compatibility work for Classic Windows apps and you might see a new dialog box appear in the places where Classic Windows apps previously asked you to set your default."

因为这次改动，微软在 Default Programs 和 File Association Example 顶部都挂了一条 Important："This topic does not apply for Windows 10. The way that default file associations work changed in Windows 10."。所以凡是让你"直接改 HKCR\.ext 的默认值来设置默认应用"的老教程，在今天只对传统 ProgID 有效，对新式打包应用基本无效。

那么改完没生效、要重启才好，是不是也写进文档了？是。示例场景那一页的 Note 逐字是："Whenever a file association is created or changed, notify the system that a change has been made by calling SHChangeNotify, specifying the SHCNE_ASSOCCHANGED event. If this not done, the Shell might not recognize any changes made until the system restarts."——程序自己改完不发这个通知，就得等系统重启；手改注册表的普通人没有发通知的能力，所以改完后注销一次或重启资源管理器是正常步骤，不是"改坏了"。

至于要不要顺手把 UserChoice 也一起改：不建议。这一层是 ProgId 加 Hash 两个值（本机所有条目的 Hash 都是 12 个字符），微软没有公布这个校验值的生成规则，也没写"该怎么填"。本机做过一次对照：手写一个指向不存在 ProgID 的 UserChoice、配上一个任意 Hash，注册表照收并留存下来，但那个 ProgID 顺着查下去解析不出任何命令。这正好说明"从别人电脑复制 UserChoice 键"这类教程为什么时有时无。要改就用界面改，让系统自己写这条记录。

想彻底重建一个文件类型，注册表要写哪几个键？

如果是自己造的文件格式，或者关联被某个安装程序改坏了想复原，微软给的完整样板在 File Association Example（2021-04-19 更新）。一个 ProgID 应有的形状是：默认值是友好名称，CurVer 指向当前版本，DefaultIcon 给图标，shell 下面挂命令，其中执行串的写法是 "%ProgramFiles%\LitwarePlayer\LitwarePlayer.exe" "%1"。扩展名那一侧则写三条：默认值指向 ProgID、PerceivedType、Content Type。

三条 Best Practices for File Associations（2022-01-26 更新）里的建议，正好对着三类常见故障。第一是版本号："Always use versioned ProgIDs, even if there is only one version of the ProgID. Versioned ProgIDs help to avoid ProgID conflicts and overwrites."——不带版本的 ProgID 容易被后装的软件直接盖掉。第二是路径写法：文档建议用可扩展字符串（REG_EXPAND_SZ）而不是硬编码路径，例子是把 C:\WINNT\hta.exe,1 换成 "%SYSTEMROOT%\hta.exe,1"——装在别的盘就失效的关联，多半是硬编码了盘符。第三是把整条链子解释清楚的这段："MyProgram interprets that the first argument is C:\Program, and the second argument is Files\My, which is not the intended behavior."，原因正是命令串里没给 %1 加引号——"双击一个在'文档'目录里的文件打不开、双击桌面文件却正常"，八成是这个。文档同时给出了正确写法："%SYSTEMROOT%\MyProgram" "%1" "%2"。本机三条真实命令正好把这条规矩的两头都摆出来了：系统自己的 txtfile 是 %SystemRoot%\system32\NOTEPAD.EXE %1（两处都没引号，但 %SystemRoot% 展开成 C:\Windows、文件名也没空格，所以一直没事）；Chrome 的 ChromeHTML 是 "C:\Program Files\Google\Chrome\Application\chrome.exe" --single-argument %1（程序路径加了引号，因为它就装在带空格的 Program Files 里）；而本机 .txt 的 UserChoice 指向的 Applications\Notepad4.exe，它的命令是 "D:\Notepad4\Notepad4.exe" "%1"，连文件名的占位符都加了引号——这是最稳的写法。还有一句值得记住：We recommended that you do not copy existing file associations from the registry. This often leads to the propagation of poorly formed file associations.

有些扩展名不需要 ProgID 也能正常工作，这一点常被当成"关联丢了"。本机 .pdf 的三层默认值全是"键存在但没有默认值"，可它照样能双击打开，靠的是 Content Type 为 application/pdf、OpenWithProgids 里有 ChromePDF 与 MSEdgePDF 这两个候选；.jpg 则有 PerceivedType=image 加上一串候选 ProgID。部署文档的 Tip 3 把这种"没登记也能用"说透了："If a device has only one application that can handle a specific association, that application will appear as the default for that type, even though there is no explicit choice in the registry."，紧接着还有半句："Exporting the default applications to XML will not gather these implied settings."——推导型默认连导出都导不出来。

要管一批电脑，正规通道是那份 XML，而不是往每台机器导注册表。四条命令按文档逐字是：Dism /Online /Export-DefaultAppAssociations:"F:\AppAssociations.xml" 导出参考机配好的关联，Dism.exe /Image:挂载目录 /Import-DefaultAppAssociations:文件 导入镜像，/Get-DefaultAppAssociations 查看，/Remove-DefaultAppAssociations 移除。同一页的两条提醒很实在：别把自己不关心的条目直接删掉，"Otherwise on the first boot, the missing entries may trigger a flurry of notifications on the first boot saying 'An app default was reset'"；以及 XML 要跟着系统大版本刷新，例子是 Windows 10 1703 里 Microsoft Edge 注册了 epub，还在用 1607 的 XML 就会收到这条通知。真要精简，文档给的做法是导出一份当前版本的完整默认表，再单独维护一份只含自己那几条的 XML，两份先后导入——并注明 "Importing xml only handles the last file imported. Results are not cumulative if you import multiple files."，所以得手工合并成一份。

常见问题 FAQ

双击时弹"你想用什么方式打开此文件"，是不是文件坏了？

不是文件的问题，是这一层查不到可用命令。按"怎么查出某个扩展名在你电脑上到底归谁"那一节的四条命令查：三层都没有默认 ProgID、或者 ProgID 在但 shell\open\command 查不到，都会是这个提示。前者用右键"打开方式 > 选择其他应用"勾上"始终"就能修；后者要么重装那个程序补齐登记，要么手工把 open 命令写回去。

改扩展名能把 .md 变成 .txt 吗？

不能。微软中文页的口径是逐字的："你可以更改文件扩展名，但这不会将文件转换为其他格式，也不会更改除文件名之外的任何文件相关内容。"改名只是改了匹配用的那个字符串，真正决定谁能打开的是"同一个扩展名为什么有三份记录"那一节讲的三层登记。

用 NoOpenWith 屏蔽一个程序，会不会顺手把它自己的功能也弄坏？

影响的范围只有"未关联文件类型"时的候选列表，另外还有一条副作用写在同一页：Prevents pinning a file to the application's Jump List through drag-and-drop, unless the application is specifically registered to handle that file type.（除非该程序确实注册处理这类文件，否则不能再用拖放把文件固定到它的跳转列表）。而且它挡不住用户手动浏览——文档原话是 "a user can manually browse to any executable file"。

卸载软件后"打开方式"里的名字怎么清干净？

分两种：只在这个扩展名上出现的，删 FileExts\扩展名\OpenWithList 这一个子键最省事；到处都列出来的，去 HKCU\Software\Classes\Applications\程序名.exe（当前用户）或 HKCR\Applications\程序名.exe 加 NoOpenWith。删之前先 reg query 看一眼，删的时候记住自下而上的顺序，父键还有子键时 Windows 会拒绝。

网上流传的"assoc .txt=wordpad"这种修复命令安全吗？

命令本身是微软的，但有两个前提：必须在管理员的命令提示符里跑（PowerShell 只能写成 cmd /c 开头），而且它只改机器级那一份。如果你的默认程序记录其实写在当前用户的 FileExts\UserChoice 里，改完 assoc 双击仍然照旧——这不是命令坏了，是你改的不是生效那一层。

只读脚本会不会把关联改乱？

本文给的命令全部是 reg query，只读不写。要动写操作（reg add、reg delete）之前，先把要改的键用 reg export 存成 .reg 留底，改坏了直接双击导回即可；涉及 HKLM 的写法需要管理员权限，只改 HKCU 的部分标准用户就能完成。

写在最后

三层记录各司其职：HKLM\SOFTWARE\Classes 是这台电脑所有人共享的默认，HKCU\Software\Classes 是"我这个用户不同意默认"，FileExts\扩展名\UserChoice 是"我在对话框里勾过始终"。查的时候按这个顺序读，改的时候从设置里的"默认应用"或右键"打开方式"改起；assoc 与 ftype 只在你想核对机器级默认和命令串时才有价值，而且它们看不见当前用户那一半——这一点本机用 98 个只登记在 HKCU 的扩展名验证过。至于"打开方式"里的长名单，先把两类分开：以应用模型标识出现的、以及磁盘上还能找到程序的，都不是垃圾；真正该清的只是那些磁盘上已经不存在的文件名。

本文所有注册表读法与命令返回结果核验于 2026-11-02，以微软官方文档与后续系统版本为准。