VSCode 保存卡在“正在获取代码操作”是因 editor.codeActionsOnSave 启用的某插件响应慢或卡死导致等待超时；常见原因包括 ESLint/Prettier 耗时规则、未忽略的 node_modules 或不稳定扩展。
VSCode 保存时卡在“正在获取代码操作”是什么原因
这是 VSCode 的 editor.codeActionsOnSave 功能在后台尝试自动执行修复（比如格式化、修复 import、添加缺失类型等），但某个启用的代码操作插件响应慢或卡死，导致保存流程阻塞。不是崩溃，也不是配置错误，而是「等待超时未结束」。
常见诱因包括：eslint 或 prettier 插件配置了耗时规则（如全文件 type-check）、项目中存在大体积未忽略的 node_modules、或者某扩展注册了不稳定的代码操作提供者。
怎么快速禁用或排查具体是哪个操作在拖慢保存
先临时关闭所有保存时自动操作，验证是否真由它引起：
- 打开设置（
Ctrl+,/Cmd+,），搜索codeActionsOnSave - 点击右侧铅笔图标，选择「在 settings.json 中编辑」
- 将当前值设为
{}或直接删掉该配置项（默认就是空对象，不触发任何操作） - 保存后试一次 Ctrl+S —— 如果右下角不再转圈，说明问题确实在这里
如果想保留部分功能，不要写成 "source.fixAll": true 这种笼统配置，改用明确开关：
{"editor.codeActionsOnSave": {"source.fixAll.eslint": true,"source.organizeImports": true}}
这样能避免未知扩展悄悄注入耗时操作。
为什么 source.fixAll 比 source.fixAll.eslint 更容易出问题
source.fixAll 是通配符，会匹配所有注册了 CodeActionKind.SourceFixAll 的扩展，包括你没意识到在运行的插件（比如某些 TypeScript 工具、Vue 插件、甚至主题附带的辅助功能）。而 source.fixAll.eslint 只调用 ESLint 扩展提供的修复逻辑，范围可控、行为可预期。
- 检查已启用的扩展：禁用近期新装的 Linter/Formatter 类插件，逐个重启测试
- 终端里运行
code --status查看是否有扩展长期占用 CPU - VSCode 启动时加
--disable-extensions参数测试，确认是否纯编辑器问题
还有哪些隐藏配置会让保存变慢
除了 codeActionsOnSave，以下设置也会在保存瞬间触发额外工作流：
-
"editor.formatOnSave": true—— 格式化本身可能依赖外部进程（如 Prettier CLI），路径不对或配置错会卡住 -
"files.associations"配置了错误的语言绑定（比如把.js绑定到typescriptreact，却没装对应语言服务器） - 工作区根目录下有
.eslintrc.js等配置文件导出了异步函数（ESLint 不支持异步配置） -
"typescript.preferences.includePackageJsonAutoImports"设为"auto"且 node_modules 过大
这些不会显示“正在获取代码操作”，但现象一致：保存后右下角转圈、文件实际已写入磁盘、光标卡顿。
真正麻烦的是那些没报错、也不弹提示的隐性等待——它们往往藏在扩展的生命周期钩子里，关掉 codeActionsOnSave 只是绕过症状，要根治得看扩展输出通道里的日志，或者换更轻量的替代方案。
