加载失败
Pyrefly 是 Meta 推出的 Python type checker 和 VS Code extension。争议点在于它在激活时会把 `disableLanguageServices = true` 写进用户的全局 `settings.json`，并针对 basedpyright、windsurfpyright、cursorpyright 以及 Pylance 这类 Python 扩展生效，等于主动关闭其他语言服务。由于多个 Python 扩展在 VS Code 里经常会互相冲突，项目作者可能是想用自动禁用来改善首次体验，但这种做法会跨 workspace 生效，而且卸载后也不回滚。相关讨论还提到，这类行为是否应该先弹出提示、明确告知用户，并在扩展停用时恢复设置，才是争议焦点。
原始爆料的核心是：Pyrefly 在激活后会直接把 `disableLanguageServices = true` 写入用户的全局 `settings.json`，并且针对 basedpyright、windsurfpyright、cursorpyright 这些扩展生效。这里用的是 `ConfigurationTarget.Global`，所以影响的是整个用户环境，而不是某个单独 workspace。更严重的是，卸载后没有 `deactivate()` 清理，设置会继续留在配置里，导致被禁用的扩展仍然失效。作者还给出真机复现和源码位置，认为至少应该先征得用户同意，再在停用时恢复。
另一派认为这更像是为了处理 Python 扩展冲突而做的快捷方案，而不是恶意破坏。有人指出，VS Code 或其衍生编辑器里，多套 Python language extension 同时启用时，经常会互相抢占 go-to definition、hover、completion 等能力，先禁掉冲突项能让默认体验更顺。也有人提到安装说明和功能介绍里本来就写了会禁用 Pylance，说明这并非完全隐藏的行为。基于这个视角，争议重点不是“能不能自动处理冲突”，而是实现方式是否过于粗暴。
即便承认自动处理冲突有现实理由，仍有不少评论强调不能未经允许改用户配置。有人建议至少在安装时弹出通知，明确会禁用哪些扩展，而不是静默写入设置。还有人明确反对把全局配置当成产品优化的副作用，认为无论初衷如何，都应该在 `deactivate()` 中回滚。这个观点把问题从是否方便，转移到用户控制权和可逆性上。
评论里也有明显的品牌情绪，有人直接用“Meta 标签”来预设其会带来不想要的额外功能。还有人把这事归因于“vibe-coding”，暗示更像是随手拼出来的实现，而不是经过严谨设计的产品决策。这个分组并不深挖技术细节，更多是在表达对大厂扩展行为和代码质量的不信任。
VSIX: Visual Studio Code 扩展的安装包格式，常用于发布和审计扩展内容。
ConfigurationTarget.Global: VS Code API 中把设置写入全局用户配置的目标，会影响所有 workspace。
deactivate(): VS Code 扩展的生命周期回调，通常用于停用或卸载时做清理和回滚。
language server: 提供 go-to definition、hover、completion 等代码智能功能的后台服务。