一个 Python 开发者最烦的故障，不是报错。
是补全忽然没了，hover 没了，跳转没了。扩展列表看起来都还在，VS Code 也没明确提醒。你以为是编辑器抽风，结果可能是另一个扩展替你改了全局配置。
这次被点名的是 Meta 的 VS Code 扩展 Pyrefly。GitHub 上有公开 issue 指控：Pyrefly 激活时会静默修改用户全局设置，把三个具名 Pyright 派生扩展的语言服务关掉。卸载 Pyrefly 后，这些设置仍然保留。
这还不是最终裁决。也不能直接扣“恶意”帽子。但材料里有源码锚点，也有 VSCodium 与 VS Code 1.118.1 干净 profile 的复现。对开发工具来说，这已经不是小瑕疵。
Pyrefly 被指改了哪些设置
目前材料指向的不是所有 Python 扩展，而是三个具名 Pyright 派生扩展。
| 受影响扩展 ID | 被写入的设置 | 直接结果 |
|---|---|---|
detachhead.basedpyright | basedpyright.disableLanguageServices = true | BasedPyright 语言服务被关闭 |
codeium.windsurfpyright | windsurfPyright.disableLanguageServices = true | Windsurf Pyright 语言服务被关闭 |
anysphere.cursorpyright | cursorpyright.disableLanguageServices = true | Cursor Pyright 语言服务被关闭 |
关键不在“有冲突”。关键在写入位置。
issue 指称，Pyrefly 写的是全局 settings.json，对应源码里的 vscode.ConfigurationTarget.Global。这会影响这台机器上的所有 workspace，而不是只影响当前项目。
源码锚点也很具体：相关逻辑位于 lsp/src/extension-interop.ts，逐个硬编码扩展 ID；并在 lsp/src/extension.ts 激活时无条件调用。这个形态不像通用冲突检测，更像对特定扩展逐名关停。
复现路径也不绕。
在 VSCodium 里，安装 basedpyright 后再安装 Pyrefly，打开 Python 文件，全局配置里会多出 basedpyright.disableLanguageServices: true。卸载 Pyrefly 后，这行仍在。VS Code 1.118.1 的干净 profile 也被复现出同样行为。
用户最难发现的地方在这里：坏掉的是别人的扩展，留下痕迹的是全局配置，消失的是安装过的 Pyrefly。锅会在空气里转圈。
受影响的人该怎么处理
最直接受影响的是两类人。
一类是 VS Code / VSCodium 的 Python 开发者，尤其是已经在用 basedpyright、Windsurf Pyright 或 Cursor Pyright 的人。如果装过 Pyrefly，又发现补全、诊断、跳转异常，先别急着重装编辑器。
去用户全局 settings.json 查这几个键：
- `basedpyright.disableLanguageServices`
- `windsurfPyright.disableLanguageServices`
- `cursorpyright.disableLanguageServices`
如果它们被写成 true，而你仍想使用对应扩展，就删掉这行，或改回 false。
在 VS Code 里，可以从命令面板打开用户设置 JSON：运行 Preferences: Open User Settings (JSON)。VSCodium 的入口类似。团队里如果有人统一发开发环境配置，也应该查一下模板和个人全局设置有没有被污染。
另一类是企业或小团队的工具维护者。这里的风险不是“某个插件不好用”，而是环境可重复性变差。今天某个扩展写了全局配置，明天新人入职、CI 辅助工具、远程开发环境都可能出现难解释的差异。
团队现在更稳妥的动作，是延后把 Pyrefly 放进统一推荐清单。至少等三个问题有更清楚的答案：是否改成显式提示，是否限制到 workspace，卸载时是否清理写入项。
还有一个附带争议：Pyrefly 的 package.json 声明强依赖 ms-python.python。在 VSCodium 和 VS Code 中，安装 Pyrefly 会连带安装 ms-python.python、ms-python.debugpy、ms-python.vscode-python-envs；卸载这些依赖也会带走 Pyrefly。
issue 的说法是，Pyrefly 核心 LSP 能力主要跑在 pyrefly binary 上，对 Microsoft Python 扩展的依赖更多用于查询解释器路径、服务 Run File / Run Test 这类 CodeLens 功能。这个判断还需要更多上下文核验。
但影响已经很具体。普通 VS Code 用户可能只是多装几个扩展；VSCodium 用户，或刻意避开 Microsoft 扩展的开发者，会把它看成没有充分暴露的副作用。
真正的问题是默认权被静默改写
给 Pyrefly 找一个善意解释并不难。
Python 语言服务器确实容易打架。补全、诊断、跳转、类型检查，多个 LSP 同时抢同一份文件，体验会乱。一个新工具想保证自己能跑起来，这个动机不奇怪。
但动机不能替代边界。
如果 Pyrefly 需要独占 Python 语言服务，它可以弹窗说明。可以只改 workspace。可以做冲突检测。可以写日志。也可以在卸载时恢复自己改过的配置。
现在公开指控里的行为效果是：用户没有确认，竞品被关闭，配置长期留在全局设置里。
这就越过了普通兼容性冲突的线。
开发工具的信任，靠的是一条很朴素的规矩：你可以建议我怎么配，但不能偷偷替我决定。尤其不能把决定写进全局设置，再让用户自己去排雷。
“天下熙熙，皆为利来。”这句话放在开发者工具生态里并不重。早年的浏览器默认搜索、手机预装应用、系统文件关联，争的都是同一件事：谁能在用户做选择之前，先把路铺好。
VS Code 扩展生态当然不是操作系统。Pyrefly 也不是浏览器战争里的主角。类比只能到这里为止。
但权力结构有相似处：谁掌握语言服务器，谁就更接近开发者的日常工作流。补全、诊断、跳转、测试入口，后面都能接 AI 编程助手、云服务、企业策略和默认推荐。
入口越底层，默认权越值钱。
我不太买账的是“为了体验只能这么做”。真为了体验，路径有很多。静默全局写入、卸载不清理，是最省事的一条，也是最伤信任的一条。
接下来要看的不是口头解释，而是代码和行为有没有改。
如果后续版本改成显式提示、workspace 级配置、可回滚设置，这可以被解释为实现疏漏。如果仍然维持硬编码竞争扩展 ID、激活即全局写入，那就很难再说只是粗心。
这次争议最后可能会被修掉。但它留下的提醒不会消失：AI 时代的开发工具越来越主动。越主动，越不能绕过用户授权。模型看着更强，产品反而可能更虚。