电脑体检与清理

一台用了一两年的 Windows 电脑，很少是"坏了一个地方"，而是一堆小事叠在一起：
右键要等两秒、开机要等一分钟、C 盘只剩 18%、输入法顺手带了五个用不上的工具还占着几个 G。

这个技能的路子是：从最小的那件烦心事查起，一直查到整机账本。
所有诊断先只读，把家底摸清、把数字量出来，再决定动哪里；凡是要改要清的，
改前留原值、改后给还原文件，每一条都能退回去。

什么时候用

§0 先跑一遍只读体检（不改任何东西）

python scripts/pc_check.py                # 全部七个模块，控制台彩色摘要
python scripts/pc_check.py --report out.md  # 同时输出 Markdown 报告
python scripts/pc_check.py --only menu,ime  # 只查指定模块

模块代号：menu 右键扩展 · ime 输入法 · startup 启动项 · proc 进程内存
· disk 磁盘与大目录 · apps 已装程序 · events 稳定性事件

脚本特点（这些设计都是被坑出来的，别改）：

• 纯只读：只 OpenKey/EnumKey/QueryValueEx 和 os.walk，不写一个字节；
• 不走 reg.exe：本机实测 reg.exe、sc.exe、schtasks.exe 都在安全策略黑名单里，
  一调就 Permission denied，只能用 Python winreg；
• 子目录独立限时：大目录扫描如果所有目录共用一个 deadline，
  AppData 一跑完后面的 Documents/Downloads 会被饿死成 0 MB，看起来像空目录；
  未扫完的项一律标 ≥（下限值），不许当精确值用；
• 输出编码兜底：本机 PYTHONIOENCODING=utf-8 会传给子进程，Python 输出是 UTF-8，
  而 tasklist/wevtutil 是 GBK —— 统一"先 UTF-8、失败退 GBK"，否则 ✅/⚠ 会被
  errors="replace" 吃掉，导致"全部正常"的判定失效。

体检报告要落到一个固定位置（建议 %USERPROFILE%\.workbuddy\pc-health\reports\），
文件名按用户的公文命名习惯走 YYYYMMDD-电脑体检报告-workbuddy.md。

§1 右键菜单：最容易被感知的那两秒

1.1 为什么会慢（先讲清原理，用户才信你的方案）

右键菜单里每一项背后是一个 DLL。你点右键的那一瞬间，资源管理器要把这一长串 DLL
全部 LoadLibrary 一遍，再调用各自的 QueryContextMenu。任何一个卡住，整张菜单就得等它超时。

实测一台办公电脑，右键菜单挂了 86 项扩展：

*\shellex\ContextMenuHandlers                 23 项
Directory\shellex\ContextMenuHandlers         17 项
*\shellex\PropertySheetHandlers               12 项
Directory\Background\shellex\...              11 项
Drive\shellex\ContextMenuHandlers              8 项
Folder\shellex\ContextMenuHandlers             7 项
AllFilesystemObjects\shellex\...               6 项
Directory\shellex\PropertySheetHandlers        2 项

这 86 项里第三方占 37 项，而同一个功能会被注册到多个挂载点
（WPS 一个"打开方式"就占了 4 处），真正天天用的不超过 10 个。
右键慢的本质不是电脑性能不行，是待加载的扩展太多。

1.2 诊断：找 CLSID，找 DLL，找厂商

python scripts/pc_check.py --only menu          # 全部扩展 + CLSID + DLL + 厂商归属
python scripts/pc_check.py --only menu --json menu.json   # 存快照，下次比对谁新装了东西

必查的注册表位置（照抄，漏一个就漏一类）：

HKCR\*\shellex\ContextMenuHandlers                       所有文件
HKCR\AllFilesystemObjects\shellex\ContextMenuHandlers
HKCR\Directory\shellex\ContextMenuHandlers                文件夹
HKCR\Directory\Background\shellex\ContextMenuHandlers     文件夹空白处
HKCR\Drive\shellex\ContextMenuHandlers                    盘符
HKCR\Folder\shellex\ContextMenuHandlers
HKCR\*\shellex\PropertySheetHandlers                      右键「属性」
HKCR\<扩展名>\ShellEx\{8895b1c6-b41f-4c1c-a562-0d564250836f}   预览处理器
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers
HKLM\...\Explorer\ShellIconOverlayIdentifiers             图标角标
HKCU\...\Explorer\FileExts\<扩展名>\UserChoice            默认打开程序

三个关键 GUID

看 DLL 路径判厂商（要带路径分隔符匹配，别用裸词，理由见下）

> ⚠ 厂商抢排序的手法，必须做键名归一化，否则永远匹配不上
>
> | 厂商 | 键名前缀 | 码点 |
> |---|---|---|
> | 360 | 两个控制字符 | U+0001 U+0001（'\x01\x01360Zip'） |
> | 搜狗 | 4 个空格 | U+0020 |
> | 华为 / 百度网盘 / 微信云盘 | 3—7 个空格 | U+0020 |
>
> 控制字符排序比空格还靠前，所以 360 的项永远钉在右键菜单最顶端。
> 两个后果：① 比对前先 re.sub(r"^[\s\x00-\x1f]+", "", name) 归一化；
> ② 用完整路径字符串 OpenKey(root, "...\\x01360Zip") 可能打不开这个键（报错 2），
> 但用父句柄 + 相对名 OpenKey(parent, name) 可以正常打开——枚举子键必须用后者。
>
> 这类项还会挂在 ProgID 上（如 360zip.ZIP\shellex\ContextMenuHandlers\{...}），
> 不在 * / Directory 等常规位置，表现为"右键压缩文件时也会卡"。

1.3 预览与缩略图慢，是另一码事

图片"预览慢"通常是第三方抢注了预览处理器，或者默认打开程序被换成了重型软件。

• 预览处理器 → 查 HKCR\.jpg\ShellEx\{8895b1c6-...}，看指向谁的 CLSID；
• 默认打开程序 → 查 HKCU\...\FileExts\.jpg\UserChoice。

> ⚠ UserChoice 有哈希校验，不能用脚本改。系统会判为无效并重置。
> 只能引导用户去「设置 → 应用 → 默认应用」里手动改。别浪费时间写注册表。

> ⚠ 置空预览处理器之前，先确认系统有没有兜底的。
> 查 HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\PreviewHandlers 的项数——
> 实测有台机器这里是 0 项，说明系统没装自带图片预览处理器。
> 这种情况下置空第三方处理器，预览窗格看图片会显示"没有可用的预览"
> （缩略图和双击打开不受影响）。必须提前把这个取舍告诉用户，并给一键还原。

1.4 修法：HKCU 覆盖法（无需管理员、零破坏）

原理：HKCU\Software\Classes 优先级高于 HKLM\Software\Classes。
在同名子键下写一个空的 REG_SZ 默认值，合并后 CLSID 为空 → 该项不加载。
不删除、不修改任何原有配置，删掉 HKCU 这个键就完全还原。

python scripts/pc_fix.py --menu --check     # 只比对，列出"该屏蔽但没屏蔽"的项
python scripts/pc_fix.py --menu             # 执行屏蔽（幂等，跑几遍都一样）
python scripts/pc_fix.py --menu --restore   # 一键还原

⚠ 动手前必须先判"原值注册在哪一层" —— 这决定还原方式：

很多国产软件（实测 WPS、搜狗输入法）把外壳扩展注册在 HKCU，不是 HKLM。
此时"写空值"是改写它们自己的键，不是另建覆盖。后果有两个：

1. 还原必须"原值写回"，不能只删键 —— 否则这些项会彻底消失，而不是恢复原状；
2. 软件升级会直接覆盖掉空值，屏蔽失效。

所以第一步永远是：从 HKCR（合并视图）在改动前读出全部原值，
存成 original-values.json，这份文件丢了就没法真正还原。

# HKLM 缺失 + HKCU 存在  →  原值在 HKCU
sub = loc + r"\shellex\ContextMenuHandlers" + "\\" + name
in_hklm = exists(HKLM, r"SOFTWARE\Classes\" + sub) or \
          exists(HKLM, r"SOFTWARE\Classes\Wow6432Node\" + sub)

1.5 抗篡改：一次性优化必然会被软件升级破坏

交付物里必须带一个幂等的体检修复脚本，否则过两个月又慢回去，用户觉得你没干活。

scripts/pc_fix.py
    ├── discover()   扫 HKCR，按厂商特征识别所有第三方外壳扩展
    ├── state.json   记录"应屏蔽项"历史 ★关键
    ├── check()      比对当前状态 vs 期望状态
    ├── fix()        自动修回
    └── reports/     每次留报告，能看出"谁改回了什么"

state.json 是精髓：只靠即时扫描会漏检"整键被删"的情况——那时该键在 HKCR 里
已经不存在，扫描永远发现不了，而历史记录能保证它仍被持续核查。

三层防护：

> 想要"双击就跑"的入口：执行 python scripts/make_launcher.py，
> 它会在同目录生成「电脑体检.cmd」，双击即跑只读体检，报告写到 scripts\report\report.md。
> 之所以不把 .cmd 直接放进包里 —— SkillHub 的发布白名单不接受批处理文件（返回 400），
> 只能在用户本机现生成。

交付后要做一次"模拟篡改"实测：故意删一个键、把一个 DWORD 改回去，
跑体检 → 修复 → 复查。这既验证脚本真管用，也是给用户看的最有力证据。

§2 输入法：最容易被忽略的"体积大户"和"右键元凶"

输入法在电脑里是个特殊物种：它必须往所有进程里注入 DLL，所以它既能拖慢右键、
又能让文件删不掉、还能顺手带一堆八竿子打不着的工具。

2.1 查体积：一看程序目录，二看 AppData，三看"带了什么"

python scripts/pc_check.py --only ime

它做三件事：

1. 量程序目录：C:\Program Files (x86)\SogouInput 等常见位置逐个体积 + 文件数；
2. 量数据目录：%APPDATA% / %LOCALAPPDATA% 下同品牌目录——
   这一块经常比程序本体大几倍，而且用户完全不知道它在那；
3. 列捆绑物：按品牌关键词扫 AppData 下的独立工具目录。

实测一台电脑，搜狗输入法早就卸了，但 AppData 里还留着两个"顺手装的"工具：

   42.7 MB   989 文件   %LOCALAPPDATA%\fastpdf_sogou     ← 搜狗"快PDF"
   25.4 MB    91 文件   %LOCALAPPDATA%\kzip_sogou        ← 搜狗"快压"

这就是"输入法捆绑"的典型形态：装输入法时一路"下一步"，捎带装了两三个小工具，
名字还带下划线后缀，在"程序和功能"里根本找不到，只能靠扫目录发现。

2.2 判断标准（给用户一个可比较的尺子）

> 数值是经验区间，只要明显超出就值得展开看一眼里面是什么；
> 重点不是"哪个输入法好"，而是"这台机器上它到底占了多少、带了什么"。

2.3 推荐微信输入法：给三条硬理由，别只说"好用"

用户问"换哪个输入法"，不要给一堆选项让他选。给结论 + 理由 + 代价：

推荐理由（可验证的三条）

1. 不捆绑：安装包只装输入法本体，AppData 下不会多出 *_sogou 这类寄生目录；
2. 不抢右键、不装看图工具：没有 sogou-FastPicExt、kfastpic_sogou 这类外壳扩展，
   装完之后右键菜单不会变长——这一条对"右键慢"的用户最直接；
3. 体积可控：程序 + 用户数据通常 1—2 GB 量级，比"输入法 + 看图 + 压缩 + PDF"合体小得多。

要如实告知的代价（这些必须说，否则用户换完会来问）

• PC 端不支持导入词库。实测微信输入法 PC 1.4.2.12：程序文件里能搜到
  wt_pc_app_action_click_import_terms 这类埋点，看着像支持导入，但界面文案里
  「导入」「导出」「批量」「自定义短语」各出现 0 次——埋点不等于本端有界面。
  结论：个人词库靠自动积累 + 跨设备同步，封闭设计。
  换之前务必先把老词库导出/备份（见 references/ime-bloat.md 的词库迁移一节）；
• 「快捷发送」上限 1000 条，且要手动添加；
• 涉密岗位建议开「单机/离线模式」。

> ⚠ 别用搜索回答"某输入法支不支持导入词库"。实测中文社区里同一个问题有
> 两种完全相反的答案。可靠办法只有一个：数目标程序里"导入/导出/批量"这些界面文案
> 出现几次（中文字符串通常是 UTF-16LE）。次数为 0 ⇒ 本端没有这个界面。
> 具体查法见 references/ime-bloat.md。

2.4 卸载输入法：必须重启，不许硬删

实测踩过：Program Files (x86)\SogouInput 有 16 个文件怎么都删不掉，
SGTool.exe 杀掉后立刻自己复活。

根因：SogouPY.ime / SogouTSF.ime 作为输入法 DLL 被注入到几乎所有正在运行的进程
（Word、Edge、微信、甚至 prevhost）。这些进程都在卸载前就启动了，文件被锁死。

正确处置顺序：

1. 先删能删的（ProgramData 数据目录、注册表项、HKCU 键）；
2. 剩下被占用的文件用 MoveFileEx(path, None, MOVEFILE_DELAY_UNTIL_REBOOT=4)
   登记"重启时删除"（写入 PendingFileRenameOperations）；
3. 老老实实让用户重启，不要试图杀进程硬删。

实测重启后：四个搜狗目录全部消失、3537 项待删队列处理完毕、输入法注册干净。
验证口径：HKCU\Keyboard Layout\Preload 只剩 00000804，
HKLM\SOFTWARE\Microsoft\CTF\TIP 下该品牌的 CLSID 归零。

§3 开机启动项：托盘那一排是开机慢的主因

3.1 三个来源，缺一个就漏

1. HKCU\...\Run、HKLM\...\Run、HKLM\...\WOW6432Node\Run、RunOnce
2. 启动文件夹：%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup 与
   C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
3. 第三方自启服务（HKLM\SYSTEM\CurrentControlSet\Services 里 Start=2 的）
   —— 这一层在任务管理器里看不到，却经常是开机 60 秒的大头

3.2 禁用：不用管理员，也去任务管理器之外做

StartupApproved 就是任务管理器"禁用"背后的机制：

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run        （对应 HKCU Run）
HKCU\...\StartupApproved\Run32                                                     （对应 HKLM WOW6432Node Run）
HKCU\...\StartupApproved\StartupFolder
HKCU\...\StartupApproved\StartupFolder32

值名 = 启动项名；值是一个 12 字节 REG_BINARY：
首 4 字节 02 00 00 00 = 启用、03 00 00 00 = 禁用，后 8 字节是时间戳（可填 0）。
删除该值即恢复默认（启用）。

> 实测一台机器 22 个注册表启动项里 13 个已被禁用——先读 StartupApproved 再报告，
> 否则会把用户早就禁掉的项又报一遍"建议禁用"，显得很不专业。

3.3 哪些能禁、哪些别动

> ⚠ 安全软件会拦截对自身注册项的写入（实测 360 安全卫士的 ZhuDongFangYu.exe、
> 火绒的 Sysdiag）。症状很典型：往同一个键写无关值成功，写它自己的条目就报
> [WinError 5] 拒绝访问。
> 这类项脚本绕不过去，必须标成"需手动"，让用户在软件自己的设置里关。
> 千万不要把它算成"可自动修复的问题" —— 否则每周巡检都报一个永远修不了的错，
> 用户三次之后就不看你的报告了。
> 诊断口径：写无关值 vs 写目标值，两者成败的差异即可确诊是"自保护拦截"而非"权限不足"。

§4 进程与内存：看清楚谁在吃

• 用 tasklist /fo csv 拿快照，按内存排序；
• 进程路径必须用 ctypes 取：OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) +
  QueryFullProcessImageNameW。同名多进程要逐个 PID 试到成功，
  否则 svchost 这类多实例进程会因首实例取不到路径而整片掉进"未识别"；
• 厂商归属有个经典坑：C:\Users\HUAWEI\AppData\... 路径里含 \huawei\，
  会把百度网盘、豆包全判成"华为"。必须先把 USERPROFILE 前缀从待匹配路径里剔除
  再匹配厂商特征串；命令串还要先 strip 掉引号（"C:\... 会导致前缀匹配失败）。

判断口径：内存占用高不等于有问题。真正要看的是"常驻 + 你不用它"。
浏览器占 3 GB 是正常的（你开了 40 个标签页），一个你没装的网盘后台常驻 400 MB 就不正常。

§5 磁盘：C 盘的空间都去哪了

5.1 别只看 C 盘根目录，黑洞常在 AppData

实测一台机器，%APPDATA%\baidu 一个目录 3948 MB，拆开看：

   635.9 MB  BaiduNetdisk\AutoUpdate\Download\MainApp\fullpackage_7605106.cab
   626.2 MB  BaiduNetdisk\AutoUpdate\Download\MainApp\fullpackage_816101.cab
   482.6 MB  BaiduNetdisk\AutoUpdate\Download\MainApp\fullpackage_7550106.cab
   481.8 MB  BaiduNetdisk\AutoUpdate\Download\MainApp\fullpackage_7570102.cab
   481.8 MB  BaiduNetdisk\AutoUpdate\Download\MainApp\fullpackage_7570103.cab

五个旧安装包，2.7 GB，全是自动更新下载下来、装完就不删的。
用户完全看不见，因为他从来不会去 AppData 里翻。

这就是"体检"和"清理软件"的区别：清理软件删的是回收站和临时文件（几百 MB），
体检找的是这种结构性浪费（几个 GB）。

同类高频目标：

5.2 缓存清理必须自带"前后实测"

删完再测一遍各目录体积与 C 盘剩余，把增减打印出来。
只报"我删了 800 MB"会和实际释放量对不上（删除可能被沙箱/回收站机制接管），
差额一大，用户就不信你了。

python scripts/pc_fix.py --clean --dry-run   # 只算能腾多少，不删
python scripts/pc_fix.py --clean             # 白名单清理 + 前后对比

§6 已装程序：卸没卸干净，怎么判

用户经常记不清"那软件到底还在不在"。判定口径按可靠性排序：

1. 卸载登记项（三个 Uninstall hive）里有没有它 —— 有 ⇒ 还在装，不要删它的服务；
2. 程序目录体积 + 文件数；
3. 服务 ImagePath 指向的文件是否还存在（注册项在、文件不在 = 无效残留）；
4. 进程/托盘还在不在。

> ⚠ "卸载登记项消失 ≠ 卸干净"。实测一台"以为卸了 360"的机器上，
> 360 安全卫士的主动防御服务 ZhuDongFangYu 仍在自启运行，
> 还留着 360AntiHijack / 360FsFlt / 360Box64 等 6 个内核驱动
> —— 也正是它导致启动项写不进去。
> 这种情况只能引导用户重装再走官方卸载，或运行残留的 uninst.exe，
> 脚本不要代为卸载（涉及内核驱动、需重启、不可逆）。

> ⚠ 先分清"残留"和"还装着"，这两者处置完全相反。
> 实测踩过：XLServicePlatform 服务启动失败、看着像残留，实则迅雷完整安装着
> （Program Files (x86)\Thunder Network 2068 MB / 2464 文件 + 卸载登记项 thunder_is1）；
> 而同一台机器上 360 安全卫士确实已卸（无登记项、程序目录只剩 45 MB）。
> 两者表现都是"服务还在 + 目录里还有东西"，只能靠登记项 + 体积一起判断。

> ⚠ 按父目录批量删之前先看里面有什么：C:\Program Files (x86)\360 下可能
> 同时有已卸载的 360Safe（可删）和仍在用的 360zip（360 压缩，不可删）。

服务启动失败要谨慎下结论：SCM 1053（服务没有及时响应启动或控制请求）
常见原因是 DLL 被安全软件拦截，而不是组件缺失——先核对
Parameters\ServiceDll 指向的 DLL 是否存在、依赖是否齐全，再说话。

6.1 装在用户目录里的软件，不必走官方卸载向导

Chromium 系国产浏览器常把程序本体 + 用户数据都放在 %APPDATA%\<品牌> 下。
此时可以手动清理，比走官方向导更可控（向导常有挽留流程、可能顺带装别的）：

1) 备份个人数据：User Data\Default 下的 Login Data / Web Data / Preferences / Bookmarks
   —— 尤其 Login Data（保存的密码），删了就找不回来
2) 关进程 → 删 %APPDATA%\<品牌> 整个目录（用户权限即可）
3) 删 HKCU\Software\<品牌>、卸载登记项、开机启动项
4) 服务注册项 + System32\drivers 下的驱动（需管理员）

驱动删除顺序：先删服务注册项（HKLM\SYSTEM\CurrentControlSet\Services\<name>），
再删 System32\drivers\<name>.sys；文件被占用（WinError 5）就登记
MoveFileEx(DELAY_UNTIL_REBOOT)，重启后彻底生效。

§7 稳定性：事件日志要聚合，不能堆

wevtutil qe System /q:"*[System[(Level=1 or Level=2)]]" /c:400 /rd:true /f:text

> ⚠ wevtutil /f:text 的输出是英文的（Event[0] / Log Name: / Source: /
> Date: / Event ID: / Level:），而且 Source: 出现在 Event ID: 之前。
> 如果拿"事件 ID"当记录切分点，Source 会被归到上一条记录上，
> 产出 Service Control Manager → 3502 这种根本不存在的组合。
> 正解：以 ^(事件|Event)\[\d+\]\s*:?\s*$ 作为记录边界。

> ⚠ 不聚合的报告等于没报告。实测近 7 天 400 条错误里，393 条是同一条噪声
> （DeviceAssociationService 事件 3502 重复刷）。按「来源 + 事件ID」聚类，
> 再把已知噪声源排除出"要不要处理"的判断，报告才有信息量。

常见噪声源（可以放心忽略）：DeviceAssociationService 3502/3503、
DistributedCOM 10016、Kernel-EventTracing 2、Perflib 1008。

真正值得看：Kernel-Power 41（非正常断电/死机）、BugCheck 1001（蓝屏）、
Disk 7/11/51（坏道/控制器错误）、WHEA-Logger 17/18/19（硬件纠错，
提示内存/CPU/PCIe 真有问题）。

§8 该不该重装：给个能用的判据

不要说"重装一下试试"，那是最不负责的建议。用这四条判：

重装前必做的三件事（比安装本身重要）：

1. 导出浏览器密码（Chrome/Edge 登录账号同步，或导出 Login Data）；
2. 记下已装软件清单（pc_check.py --only apps --report，报告里就是清单）；
3. 备份输入法个人词库——这是最不可再生的东西，换输入法/重装后基本找不回来。

工作流程（照这个顺序走，别跳）

1. 问需求：最烦的是哪一件事？（右键慢 / 开机慢 / 空间不够 / 就是想知道状态）
2. 跑只读体检：pc_check.py --report，先出数字，不谈方案；
3. 给诊断：按"现象 → 原因 → 证据（数字）→ 影响"四段说，
   每个结论都要能指到一个具体的注册表键、目录或进程；
4. 分档给方案：A 档用户权限可做 / B 档需管理员 / C 档需手动（软件自保护）；
5. 改前备份：original-values.json + reg export 备份 + 能删的文件先 copy2；
6. 执行 + 逐项验证：每改一项立刻复查，不要一口气改完再看；
7. 交付报告：数字前后对比（C 盘可用从 46.0 GB → XX GB、右键项从 74 → XX）；
8. 留抗篡改机制：一键体检 .cmd + 定期巡检，并做一次"模拟篡改"实测给用户看。

三条红线

1. 不删用户数据。Login Data（保存的密码）、输入法词库、聊天记录、Documents
   下的东西，一律先备份再动，删前逐个列出路径让用户确认。
2. 不动系统关键项。WinSxS、pagefile.sys、hiberfil.sys、Boot 配置、
   System32 下的文件，一律不碰。
3. 不代替用户做卸载决定。涉及内核驱动、安全软件、单位合规客户端的，
   只报告 + 给路径，让用户自己走官方卸载。

交付物清单

• YYYYMMDD-电脑体检报告-workbuddy.md（含前后数字对比）
• YYYYMMDD-右键菜单-A档还原-workbuddy.reg（原值写回版）
• YYYYMMDD-右键菜单-B档-需管理员-workbuddy.reg（系统级 Blocked）
• YYYYMMDD-右键菜单-B档还原-workbuddy.reg
• original-values.json（改前原值快照，丢了就没法真还原）
• pc_check.py / pc_fix.py / make_launcher.py（生成双击入口）
• 定期巡检自动化（或 Windows 任务计划）

.reg 文件必须用 UTF-16 编码写出，否则 regedit 认不出来：

with open(path, "w", encoding="utf-16", newline="") as f:
    f.write(txt.replace("\n", "\r\n"))

细节参考