你是不是也在 VSCode 里遇到过这种情景：新建一个文件，名字敲下去半天不落盘；改动几行代码按一下 Ctrl+S，右下角保存状态一直转圈；右键删除文件，光标转得像风扇，标题栏上却挂着"等待中"。我这些年做编辑器调试和排障，这种"vscode 增删改查文件，一直等待中"的卡顿，说大不大，但确实让人抓狂，而且它不像报错那样有红字提示，往往连从哪下手都不知道。这篇文章就围绕这个现象，把常见原因、排查方法和配置优化一次性讲透，适合日常用 VSCode 写代码、做笔记、管文件的所有人，尤其是被"保存转圈""文件删不掉"折磨过的朋友。
1. 现象还原：VSCode 里的"一直等待"到底长什么样
说实话，"等待中"这三个字在 VSCode 里通常不会弹个对话框告诉你"我在等文件锁"，而是悄无声息地让整个编辑器处于半瘫痪状态。我刚接触这个需求的时候，第一反应是用户的机器太老，或者目录太大，可细聊下来发现根本不是那么回事。问题的表象五花八门，但本质上都是同一个底层链路出了问题。
1.1 几种典型的卡死场景
我在实际使用和帮人排错过程中，遇到的"一直等待中"大致可以归纳成五类，每一类的表象都不同，但核心都是文件系统操作没法正常完成：
- 新建文件没反应。按完 Ctrl+N 或者右键选 "New File"，输入框在编辑器里闪烁，输入了名字回车，文件却迟迟不落盘，资源管理器里也刷不出来。
- 保存一直转圈。改完代码按 Ctrl+S，状态栏右侧那个保存图标一直转，文件内容明明已经写进去了，但 VSCode 还在"排队"，这时候你再点别的文件，新的文件也打不开。
- 删除提示"权限/占用"。右键删除一个文件，或者把某个目录拖进回收站，系统弹出"文件正在被使用"，或者干脆无响应，命令行里报 EBUSY / EPERM。
- 打开文件无限加载。双击打开一个文档，标签页一直显示"加载中"，同时打开另一个文件也一样，整个窗口就像被掐住了脖子。
- 全局无响应但 UI 还活着。鼠标能动，菜单能点，但标题栏一直显示"正在等待文件操作"。这种最坑，因为你不确定到底在等什么，也不敢乱点。
这些情况的共性是什么？都是文件操作层没有及时返回结果。VSCode 不是单线程工具，它有一个专门的文件系统抽象层去调度所有文件事件，只要这一层被堵住，你用鼠标点哪儿都白搭。
1.2 为什么说"增删改查"会一起卡
你可能觉得"增删改查"更像数据库专有名词，但放到编辑器里其实完全对应：新建对应 create，删除对应 delete，编辑保存对应 update，跳转、搜索、打开对应 read。VSCode 底层有一个统一的文件系统抽象层（FileSystem Provider），不管是本地文件、远程 SSH、还是挂载的 WSL 目录，所有操作都要经过它。
我做一个不太严谨但特别好懂的生活化类比：这个抽象层就像物业的一站式窗口，所有住户的水电煤申请都要从前台走。只要有一个住户的申请卡住了，后面的所有住户都得排队等着，哪怕你的申请只是换灯泡这种小事。VSCode 的文件系统层也一样，只要任何一个未完成的 IO 操作没结束，后台的增删改查全都得排队，表现出来就是"等待中"。
很多人在这个阶段容易走弯路：以为是某个文件坏了，或者以为要重装 VSCode。实际上绝大多数问题都出在"有一个文件操作没有正常结束，把整条流水线堵死了"。理解这一点，排查思路就清晰了——你需要的不是重装，而是把卡住的那个操作找出来。
2. 根源拆解：文件增删改查为什么会一直等
等你把"等待中"当成一个整体现象去看时，就会发现底层原因可以被拆开。我习惯把这些原因按"文件锁、会话残留、监视器压力、扩展拖累、远程通道"五个方向去归类，绝大多数案例都能覆盖。这五个方向不是孤立的，有时候两个甚至三个因素叠加在一起，让问题显得特别难缠。
2.1 "增"文件时卡住的常见原因
新建文件本身是一个轻量操作，正常情况下几百毫秒就完成，卡住通常意味着目标目录不可写，或者目录被某个后台进程锁住了。
举几个真实例子。在 Windows 上，如果另一个程序（杀毒软件、同步盘、甚至资源管理器）正在扫描这个目录，新建文件就会等扫描结束。还有一点特别容易忽略：如果当前工作区是从一个不存在的路径打开，或者路径中含特殊字符（空格、中文、~），文件系统插件可能一直重试。
还有一种情况是自动保存的"热退出"（Hot Exit）机制——VSCode 在异常关闭后会恢复上次未保存的缓冲区。如果这些缓冲区对应的文件已经被移动或删除，恢复过程就会卡住，而新建操作也要等恢复结束。我遇到过一个用户，连续一周每天开机都看到 VSCode 弹"恢复窗口"，他每次都点取消，但后台进程还在反复尝试读取那批已不存在的文件，导致新建文件永远出不来。
2.2 "删"文件时卡住的原因
删除操作失败最常见是三因素：文件被编辑器自身占用（比如你在几个标签页里同时打开了同一个文件，还有未保存的编辑）；被别的进程占用（本地服务正在读写、杀毒软件实时防护、索引服务在扫描）；或者是在远程环境下权限不足。
前面两种在 Windows 上特别典型。Windows 对文件锁的粒度没有 Linux 那么宽松，一个进程只要以独占模式打开了文件，你这边怎么删都删不掉。我见过最离谱的一次，是一个前端项目里删除node_modules下的某个子目录，卡了整整 5 分钟，最后发现是有个残留的 node 服务进程一直在读那个目录。
第三个原因容易被忽视：VSCode 的某些扩展会主动监听文件变化。如果你装了 Live Server、ESLint、自动格式化这类扩展，删除文件时它们会先拿到事件，要执行清理逻辑。一旦某个扩展的回调没有返回，删除操作就会挂起，而且这个挂起会顺着文件系统事件队列传染给别的操作。这也是为什么有时候你删一个小文件，整个窗口都卡住的原因。
2.3 "改"文件时一直转圈的原因
保存文件时转圈，是最常见、也最多人跑来问我的一个问题。这里有个很多人不知道的机制：VSCode 保存文件不是直接把内容写进磁盘，而是先写到一个临时文件，然后做替换（原子写），写完还要触发一次"文件监视"来通知扩展。整个链路里只要有一环慢，视觉上就是"一直在等待"。
具体来说，可能有这几个环节：
- 目标目录磁盘 IO 慢或故障。机械盘碎片多、NAS 网络延迟高、云盘目录同步繁忙，都会拖慢写盘。
- 自动保存（
files.autoSave）开关开着。每次输入都触发写盘，写盘任务一多，后续操作就开始排队。 - 格式化或保存时运行任务。你先打开了"保存时格式化"（
editor.formatOnSave），又配置了保存后运行 build 任务，每次 Ctrl+S 都会先跑一遍格式化加编译，中间任何一步卡住，保存状态就一直转。 - 文件被设置了只读，但用户没注意到。VSCode 会反复尝试写权限，直到超时，表现就是转圈很久才弹错误。
2.4 "查"文件时卡住的原因
这里的"查"不仅是打开文件看内容，还包括全局搜索、跳转定义、终端 grep。搜索和跳转涉及全目录扫描，一旦某些目录里塞着巨大的 node_modules、.git 对象、构建产物，扫描起来非常耗时。
如果files.watcherExclude没有把这些目录排除，VSCode 的 File Watcher 就会在后台不停遍历，导致打开文件这个"查询"操作也排队。另外，如果你开了多个工作区窗口，每个窗口各自维护一套 watcher，内存和文件句柄快速上涨，整个编辑器就开始"等"。
排除完这些，大部分人卡住的元凶往往就浮现了：一个异常扩展里的事件监听器死循环，或者过期的"未保存会话"在后台反复重试。下面进入可执行的排障流程。
3. 硬核排障：从简单到复杂的修复路径
我处理这类问题有一套固定的由简到繁的顺序，因为越简单的操作代价越小，也更安全。以下步骤不需要全都做，走到哪一步解决了，就停在哪一步。注意每改一个地方就实测一次，不要一次改一大堆配置，不然你根本不知道是谁起了作用。
3.1 第一步：缩小范围，判定是全局还是单目录
遇到"一直等待"第一件事不是改配置，而是先做对照组。用当前窗口在命令行里敲code .运行；然后再打开任意一个磁盘上干净的空目录；最后把当前工作区关闭（File > Close Workspace），看文件操作是否恢复。
我一般会做三组判断：
- 如果空目录正常、当前目录卡死，优先怀疑该目录下有异常路径（空格、符号链接、超深层级）。
- 如果所有目录都卡，再看是否是扩展或配置导致的全局问题。
- 如果关掉工作区后文件操作就恢复，说明是某个扩展绑定了工作区级事件，不是磁盘问题。
这一步能让排查范围瞬间缩小一半以上，也有利于后面发帖求助时描述问题。我试过很多次，光这一步就能解决三成用户的困惑——他们把"当前目录的问题"错当成了"VSCode 整体的问题"。
3.2 第二步：锁定可疑进程与文件占用
范围缩小后，第二步就是看底层到底是谁在占用文件。Windows 下我推荐用进程资源监视器（Process Explorer，外部工具）和系统自带资源监视器（resmon）配合。如果不想装外部工具，也可以用命令行工具定位，但注意相关工具要从官方渠道获取。
实际操作中，不借助外部工具时，最简单的办法是：
- 把可疑目录拷贝一份到别处，从新位置打开 VSCode，看操作是否正常。
- 杀掉非必要的同步盘、杀软或 NAS 客户端进程后再试一次。
- 如果用了 WSL/SSH 远程插件，直接重启插件对应的远程服务，命令面板里搜
Reload Window。
对 Linux/macOS，可以用lsof看谁打开了文件：
# 查看哪个 PID 占用了文件 lsof /path/to/file.txt多数情况下，你能看到一个"不该在这里"的进程——比如旧的命令行窗口、崩溃后遗留的 node 服务进程、甚至之前没关干净的调试会话。把这些进程处理掉，文件操作马上恢复。我印象最深的是有个用户本地起了个json-server，它把整个项目目录都监控起来了，VSCode 和它抢文件锁，抢不过就一直等。杀掉那个服务，问题瞬间消失。
3.3 第三步：处理 Hot Exit 残留与未保存会话
宏大的重装步骤先放一放，我更建议你先处理"未保存会话"。VSCode 每次异常关闭都会把未保存内容存到一个备份目录，下次启动时恢复。如果这个恢复环节卡了，你的增删改查都会排队。
处理方法很简单：
- 打开命令面板（Ctrl+Shift+P），输入 "Developer: Open Backup Storage Folder"，打开备份目录。
- 把这个目录里工作区对应的备份文件备份一份到外部（先保留，确认没问题再删）。
- 关闭 VSCode 后，把备份目录里无用或损坏的
*.json、临时文件清掉。 - 重启 VSCode，看是否恢复。
这里有个经验之谈：备份目录在异常退出后容易产生几十上百个文件，而 VSCode 启动时会等待"恢复编辑器"这个异步任务结束。如果你在恢复过程中点了别的地方，整个界面看起来就像卡死。直接清掉旧的备份，能解决大量"打开就等待"的问题。但注意：清备份等于放弃未保存的内容，操作前一定确认那些内容你已经不需要了，或者已经手动另存过了。
3.4 第四步：调整文件监视与自动保存策略
排除了占用和恢复残留后，就要看 File Watcher 和自动保存。VSCode 默认会监视工作区里几乎所有文件的变化，以支持版本控制标记、错误提示、自动刷新等功能。一旦目录结构复杂，监视器资源吃紧，新操作的客户端就开始排队。
我建议把下面这段配置加进settings.json（打开命令面板，输入 "Preferences: Open User Settings (JSON)"）：
{ "files.watcherExclude": { "**/.git/objects/**": true, "**/.git/subtree-cache/**": true, "**/node_modules/**": true, "**/dist/**": true, "**/build/**": true }, "files.autoSave": "off", "search.useIgnoreFiles": true, "search.followSymlinks": false }这段配置的核心作用是：把 node_modules、dist、build 等目录排除出监视范围，减少 watcher 压力；同时关闭自动保存，避免每次停顿都触发写盘。search.useIgnoreFiles让搜索跳过被 gitignore 忽略的目录，search.followSymlinks关闭符号链接跟随，这两个选项对搜索、定义跳转的提速非常明显。
我实测过：一个包含 5 万多个文件的大型 monorepo，加了这些配置后，打开文件从卡顿变成可以接受；如果再配上**/.cache/**、**/temp/**也一起排除，体感会更好。但注意别把所有目录都排除，否则代码提示和版本控制更新也会变慢，得不偿失。
3.5 第五步：扩展排查与配置重置
如果前三步都没效果，扩展的嫌疑就直线上升。扩展导致"等待中"最常见的原因是：扩展在onWillSave或onDidChangeTextDocument等事件里执行了耗时回调（同步遍历大文件、请求网络、编译），或者两个扩展互相等待锁。排查时我最推荐"二进制排除法"：
- 命令面板输入 "Developer: Disable All Extensions"。
- 重启 VSCode（Reload Window）。
- 一个个启用扩展，每启用一个就重复几次文件增删改查操作，直到定位到问题扩展。
- 对可疑扩展，再去看它的日志，或者用命令面板里的 "Developer: Show Logs" 查看扩展宿主进程日志。
另外要考虑配置被破坏的情况。你可以把用户设置里可疑的配置项临时移除，或者在启动时带上--disable-extensions参数验证：
# 临时禁用所有扩展启动 code --disable-extensions .如果这样启动后一切正常，那就可以确认问题在扩展或扩展与配置的交互上。此时建议把 VSCode 升级到最新稳定版，因为文件系统相关的 bug 在历史版本里出现过多次，官方修复速度也很快。我见过一个用户用的还是两年前的版本，升级之后连"等待中"三个字都很少看到。
3.6 第六步：远程/共享文件场景的专项处理
很多人是在 WSL、SSH、Docker 容器里写代码时遇到"等待中"的。这时候本地和远端走的是两个进程，文件操作要先经过"本机到远端"的协议通道。通道一旦断连或抖动，编辑器里的文件操作就会进入长时间等待。
针对远程场景，我的经验是：
- 确认网络稳定后再连。如果是不稳定的公共网络，建议先连到稳定的办公网或热点，再打开远程项目。
- 在 WSL 环境里注意把项目目录放在 Linux 文件系统内（比如
/home/user/project），而不是放在/mnt/c跨盘访问。跨盘 IO 性能很差，很容易造成等待。 - 远程模式下可以调整文件监视器为轮询模式，适当延长轮询间隔，减少对网络 IO 的依赖。
- 对共享网络盘（NAS/SMB），如果不需要实时同步，可以在设置里把
files.watcherExclude加上网络盘路径，避免网络 IO 拖慢编辑器。
远程通道的问题还有一个信号可以参考：窗口左下角状态栏显示 "SSH: hostname" 或 "WSL: Ubuntu" 时，如果等待发生在网络切换、休眠唤醒之后，大概率是通道已经过期。这时直接在命令面板执行 "Remote-SSH: Kill VS Code Server on Host" 或 "Reload Window"，强制重建连接，通常能立刻恢复。
4. 长期预防与性能优化配置
问题解决了之后，还要防止它再回来。我的习惯是把 VSCode 当成一个需要"整理房间"的环境看待，哪些文件监视、哪些不监视，哪些自动保存开、哪些关，都是有讲究的。长期预防比一次排障更值钱。
4.1 合理配置 settings.json 的关键参数
下面这组配置是我在自己长期使用中沉淀下来的，每个参数我都知道它解决什么问题，你可以直接贴进settings.json，按需调整：
{ "files.autoSave": "off", "files.autoSaveDelay": 1000, "files.watcherExclude": { "**/.git/objects/**": true, "**/.git/subtree-cache/**": true, "**/node_modules/*/**": true, "**/.next/**": true, "**/dist/**": true, "**/build/**": true, "**/coverage/**": true }, "files.exclude": { "**/.git": true, "**/.DS_Store": true, "**/node_modules": true, "**/dist": true }, "search.useIgnoreFiles": true, "search.exclude": { "**/node_modules": true, "**/bower_components": true, "**/dist": true }, "search.followSymlinks": false, "editor.formatOnSave": false }第一个值得解释的是"files.autoSave": "off"。很多人觉得自动保存很省事，实际上在文件系统 IO 慢、扩展多、项目大的场景下，自动保存会制造大量后台写盘任务。我见过一个极端例子：用户开着自动保存，一边输入一边格式化，整个窗口卡了快 20 秒。改成手动保存（Ctrl+S）之后，反而再没卡过。
第二个是search.exclude单独列，不要只依赖files.exclude。二者作用不同：files.exclude是让资源管理器不显示这些目录，search.exclude才是真正让搜索和文件扫描跳过它们。只改前者，搜索时照样会扫 node_modules，等于没优化。
第三点是"files.watcherExclude"的颗粒度。**/node_modules/*/**这种写法比**/node_modules/**更精准，但如果你的 node_modules 很庞大，直接用后者更省心。判断标准是：代码提示和 git 状态变化如果变慢，就说明你排除过度了，需要放宽。
4.2 养成健康的文件操作习惯
工具配置完了，操作习惯也得跟上。以下几个习惯我能保证对减少"等待"有实际帮助：
- 不要同时打开几十个标签页还都保持未保存状态。每多一个未保存文件，就等于多了一个"热退出"负担。
- 大文件（比如几十 MB 的日志）不要在 VSCode 里直接打开。VSCode 不是文本巨物浏览器，打开大文件会触发全文着色、标签折叠，编辑器瞬间进入假死状态。这类文件用专门的工具或命令行查看工具处理更合适。
- 定期重启 VSCode，尤其在长时间挂机、切换网络、休眠唤醒后。别信"编辑器不用重启"的说法，文件句柄和 watcher 资源是真会被耗尽。
- 删除文件前，先检查这个文件是否在某些扩展里被"引用中"。比如 ESLint、TypeScript Language Server 的缓存，有时会因为引用失效而卡住删除流程。
- 尽量不在资源管理器里右键做删除操作，尤其是大型目录。我通常先选中文件再按 Delete 键，或者直接在终端里
rm指定路径，删完再回到编辑器里确认，两侧同步更稳。
4.3 备选工具与边界认知
最后说句实话：VSCode 的文件系统抽象层设计思路很好，但它不是万能的。如果某个项目常年卡在"等待中"、怎么都调不顺，我建议你重新审视是不是"工具和场景不匹配"。
有些场景更适合换工具：
- 超大日志分析：用
glogg、lnav这类流式阅读器。 - 远程容器开发：可以先
sshfs挂载到本地再编辑。 - 批量重命名或删除大量文件：先写脚本在终端里处理，处理完再回到 VSCode 刷新。
- 只读目录、系统关键目录、大量符号链接的目录：尽量别用 VSCode 直接管理，它遇到权限和链接问题时的等待体验是灾难级的。
认知边界摆正之后，你不会再觉得"是 VSCode 坏了"，而是知道"这类场景本来就不该让编辑器硬扛"。
5. 常见问题速查表
以下这些问题是社区里问得最勤、也是我自己和身边同事踩过最多的，我把它们整理成一张速查表。遇到类似问题时，直接对照排查，能省不少时间。
| 症状 | 优先怀疑方向 | 快速处理 |
|---|---|---|
| 打开任何文件都显示"加载中" | Hot Exit 残留 / File Watcher 耗尽 | 清理备份目录；配置 watcherExclude |
| 右键新建文件，名字敲完不落盘 | 目录被同步盘或杀软占用 | 临时退出同步或杀软再试；把目录加入白名单 |
| Ctrl+S 后状态栏无限转圈 | formatOnSave 或自动保存写盘冲突 | 关闭 formatOnSave；将文件保存到本地再测试 |
| 右键删除文件提示被占用 | 本地进程锁文件 | lsof/handle 定位占用进程，杀掉后重试 |
| 删除小文件都卡，UI 死一半 | 某个扩展事件回调未返回 | Disable All Extensions 后逐个启用 |
| WSL/远程模式下访问文件慢 | 跨盘访问或通道过期 | 把项目放到 Linux 文件系统；Reload Window |
| 搜索 Ctrl+Shift+F 转圈 | 正在扫描 node_modules | 配置 search.exclude 和 useIgnoreFiles |
| 保存时页面冻结几秒 | 大文件全量格式化 | 关闭 formatOnSave；不要用 VSCode 打开超大文件 |
这张表解决的是 80% 的常见情况。如果你遇到的问题不在表内，也没关系，按上一节"从简到繁"的顺序一步步排查，大概率能找到元凶。排查时记住一个原则：改一步测一次，改完不生效就回滚，不要同时动多项配置，不然你根本不知道是谁修好的。
6. 写在最后：我的一些实操体会
这类"一直等待中"的问题，我在多个环境里排查过，说实话，能一次性确诊的比例并不高，通常都是"先怀疑文件占用，再看扩展，最后发现是某个不起眼的目录没有排除"。所以如果你折腾了半天没解决，先别急着骂 VSCode 或重装，只要按章法来，绝大多数都能找到原因。
我个人最受用的是"备份目录清理 + watcherExclude 排除 node_modules"这两招，几乎覆盖了我遇到的一半卡顿场景。另外一个小技巧：遇到顽固卡死时，敲Ctrl+Shift+P输入 "Developer: Reload Window"，很多时候只需要重载窗口就能恢复，不用关掉整个软件。还有一点，排查过程中千万不要把所有扩展一次性全禁用后就不管了，一定要逐个启用、逐个验证，否则即使恢复了，你也不知道以后该躲哪个雷。
