如果问我排错最折磨人的是什么？不是蓝屏，不是驱动，不是系统更新卡死，而是那种“看起来像小问题，但完全不讲逻辑”的异常：它不报错、不提示、不解释，只是悄悄失效，让你怀疑自己是不是哪里点错了。
这篇文章记录的，就是这样一次离奇的 Windows 异常排查经历。起因非常简单：我下载并安装了谷歌的 Antigravity IDE，在点击“Sign in with Google”时，程序却无法唤起默认浏览器（我使用的是 Chrome）。点击按钮后鼠标会短暂转圈，不到一秒就停止，既不弹出网页，也没有任何报错提示。
从“浏览器没反应”开始：最合理的怀疑路径
当一个应用无法唤起默认浏览器，第一反应往往是默认浏览器设置、协议关联损坏、注册表错误，或者系统组件异常。于是我先去问了万能的 GPT，它给了我一套非常标准、非常“Windows 式”的排错路径。我逐条照做。
- 第一步是重置默认浏览器与协议关联。我把默认浏览器从 Chrome 切换到 Edge，再切换回 Chrome，目的很明确：让系统重新生成一轮关联配置，清掉可能存在的异常状态。
结果很遗憾：依旧无法唤起 Chrome。 - 第二步是做一个最直接的实验：验证“系统到底能不能正常处理 https 链接”。我按下 Win+R，输入
https://google.com，再输入chrome https://google.com。
这一步带来了非常关键的信息：直接运行https://google.com是无效的，系统没有任何反应；但指定 Chrome 打开chrome https://google.com却完全可行。
这意味着 Chrome 本身没坏，网络也没坏，链接也没坏，问题出在“Windows 如何处理 https 协议并分发给默认浏览器”这一环。 - 第三步是经典修复组合拳：
DISM /Online /Cleanup-Image /RestoreHealth加sfc /scannow。这套操作的意义大家都懂，用来修复系统组件损坏、系统文件异常，尤其是一些“解释不清”的行为问题时，往往值得一试。
结果：依旧无效。 - 第四步是原地重装 Windows。这是很多排错建议的最终形态——能解决，但代价过高。我评估了一下：问题仅仅是“某些 URL 无法唤起默认浏览器”，直接重装属于杀鸡用牛刀，于是果断跳过。
- 第五步开始进入更底层的方向：检查注册表中
HKEY_CLASSES_ROOT\https以及HKEY_CLASSES_ROOT\https\shell\open\command的状态。按照传统经验，这些位置的异常会导致系统无法正确解析和执行 https 的打开动作。
由于新版系统启用了 AppDefaultHashRotation（有时也被称为 UserChoiceLatest 机制），相关的注册表项会被保护，无法像旧版本那样随意删除或修改。换句话说，你知道它可能在这里，但系统不允许你用传统方式处理它。
到了这里，我已经基本确定：AI 给出的标准方案对这次问题不够用。接下来只能靠自己“控制变量”，一步一步把异常逼出来。
控制变量：当异常开始暴露出规律
真正的排错往往不是“照单全收地执行修复命令”，而是提出更精确的问题：它到底在哪些条件下会失败？哪些条件下又能成功？
把 google.com 换成 g.co，结果：同样无法唤起浏览器。
这说明并不是某个特定域名被污染，而像是“谷歌系域名整体出现异常”。
于是继续换成 g.cn。结果出现了转折：g.cn 可以正常唤起浏览器。
到这里，情况已经非常诡异了：系统不是完全不能处理 https，而是“对某些域名不能处理”。而且失败与成功之间，没有任何提示、没有任何错误信息。
这类行为非常像某个组件在后台“拦截并接管”了特定域名的打开行为。
为了验证这一点，打开任务管理器，然后在命令行运行：
start https://google.com
观察任务管理器的进程列表时，看到一个东西一闪而过：Windows Problem Report。
这是一个非常强烈的信号。它通常意味着：某个进程崩溃了，系统正在生成错误报告。只是因为它出现时间太短，普通用户几乎不会注意到。
既然任务管理器已经告诉我“有东西在崩”，下一步就很明确了：去事件查看器（Event Viewer）找日志。
事件查看器：答案藏在一堆报错里
我打开 Event Viewer，顺着时间线去找刚刚触发 start https://google.com 的时间点，结果看到了一大串与 WSA 相关的报错。
WSA，也就是 Windows Subsystem for Android。
如果你经常折腾 Windows 生态，肯定不陌生。它是 Windows 上运行 Android 应用的子系统，理论上跟“打开 Chrome 浏览器访问 Google”这件事毫无关系。但偏偏日志里全是它，而且每次尝试打开谷歌系链接时，它都在报错。
Windows 有一个机制叫“Apps for websites”（网站相关的应用）。它允许系统把某些网址分配给某个应用打开，而不是交给浏览器。
例如你点击 twitter.com，可能会被系统建议用 App 打开；某些时候你点链接，甚至会直接跳转到应用而不是网页。它的本意是提升体验，但前提是“你安装的应用是正常的、接管逻辑是合理的”。
而 WSA 恰好具备这种能力。Android 应用有一类功能叫 App Links / Deep Links，能声明“某些域名归我打开”。
当我进入 WSA 的设置页后，问题几乎肉眼可见：WSA 里的 Google 和 Google Play Service 之类组件，接管了几乎所有谷歌系域名的打开行为。
换句话说：当 Windows 看到你要打开 https://google.com 时，它并没有把请求交给默认浏览器，而是把它交给了 WSA。然后 WSA 在处理这个链接时崩溃，于是看到的现象就是“鼠标转一下就没了”“浏览器完全没启动”“系统也不提示错误”。
这就是这次异常最反直觉的地方：真正阻止你打开浏览器的，不是浏览器，不是网络，不是系统损坏，而是一个看似无关的子系统抢走了链接的处理权。
尝试修复：关闭接管，再关闭支持链接
确认元凶后，修复思路反而很清晰：把域名的打开权从 WSA 手里夺回来。
按照 AI 的建议：
第一，在 Windows 的“Apps for websites”里关闭 WSA。这个位置是 Windows 级别的接管入口，关闭它相当于告诉系统：不要把网站交给 WSA 来处理。
第二，在 WSA 内部的“Open supported links”（打开支持的链接）设置里，把 Google、Google Play Service 等相关 App 的开关关掉，防止它们继续声明接管域名。
做完这些后，满怀期待地再次运行：
start https://google.com
结果非常戏剧化：WSA 直接崩溃，浏览器依旧没有被唤起。
这意味着即便关闭了接管逻辑，系统仍然在某些路径下把链接分发给了 WSA，或者 WSA 的组件依旧残留在系统的协议处理链路里。
排错到这里，其实已经进入“可以继续研究，但投入产出比极低”的阶段。
最终解决：卸载 WSA，世界恢复正常
最后我做了最粗暴、也最有效的处理方式：卸载 WSA。
卸载完成后，再次执行：
start https://google.com
Chrome 正常打开，Antigravity 的登录也可以正常唤起浏览器，一切恢复如初。
谷歌系 URL 终于被释放了出来。
复盘：遇到类似问题怎么快速定位
随着AI的爆发式进化，现在我们越来越依赖AI来解决身边的问题（包括这篇文章也经过了AI的大篇幅润色），但是有一点不容忽视，就是AI给出的回复，很大程度上还是取决于你喂给了它什么内容。
所以我认为至少现阶段还不能把AI当作是一个类似科幻片里那些超级人工智能（类似钢铁侠里的贾维斯？）。换言之就是不能将其作为一个人去依赖，而是将其作为一个趁手的工具。
不过也许再过些年AI真的能够进化成类似人脑的思考能力也说不定？
