你有没有遇到过这样的情况：在VSCode里敲完代码，按一下保存，右下角就开始转圈，状态栏冒出“正在保存文件”的字样，等了几秒钟甚至几十秒才消失；想新建一个文件，按了快捷键，结果一直处于“等待中”，整个编辑器像被冻住一样，鼠标还能动，但文件树就是没有任何反应。
我用VSCode写代码差不多十年了，从最早的版本一路用到现在，这类“增删改查文件一直等待中”的问题我前后踩过不下十次。刚开始以为是电脑性能差，后来换了顶配机器照样卡；以为是VSCode的Bug，更新了好几个版本还是会出现。直到我把VSCode的文件监听机制、扩展体系、远程开发模式都翻了个底朝天，才算是彻底摸清了里面的门道。
这篇文章我把我踩过的坑、排查的过程、以及最终生效的解决方案全部整理出来。不管你是前端、后端，还是正在用VSCode写Python、C++，只要你遇到过文件操作卡顿的问题，这篇内容都能帮你省下大把时间。全文没有任何玄学，全是可落地的排查步骤和配置方案。
1. 先搞清楚“一直等待”到底卡在哪一层
1.1 从现象判断卡顿范围
遇到文件操作卡顿，第一件事不是马上改配置，而是先回答一个问题：是所有文件操作都卡，还是某个特定文件、特定文件夹卡？
我见过很多用户上来就直接把files.autoSave关掉，或者把扩展全部禁用，结果问题依然存在。原因很简答——他们没有先判断卡顿的范围。
我一般会分三步确认范围：
- 按
Ctrl+N新建一个临时文件，输入几个字符，然后按Ctrl+S保存。如果这个操作不卡，说明VSCode本身没问题，问题大概率出在你正在操作的项目文件夹上。 - 在现有项目里随便打开一个文件，修改后保存，如果卡，再试试新建一个文件，或者重命名一个文件，看看是哪一类操作卡。是保存卡、新建卡，还是删掉卡。
- 换一个完全不同的文件夹（比如
C:\Users\你的用户名\Desktop下的一个空目录），重复上面的操作。如果空目录不卡，而你的项目文件夹卡，那基本可以断定是项目文件夹本身的规模、结构或者某些特殊文件触发了VSCode的“等待机制”。
拿我自己的经历来说，我曾经维护过一个用webpack构建的旧项目，node_modules有整整3万个文件夹，每次保存一个.js文件，VSCode都要等上十来秒。但我新建一个纯文本文件就很快，因为纯文本文件不在文件监听器的重点观察范围内，而项目里的.js、.json、.vue文件一旦变动，VSCode会尝试通知一大堆扩展（ESLint、Prettier、TS Language Server等）去重新分析和校验，整个过程就会变得非常“等待”。
1.2 根因：文件监听机制（File Watcher）是头号嫌疑
VSCode本身并不是每隔一段时间去轮询一下磁盘，而是通过操作系统的文件事件通知机制来感知文件变化。用专业的话说，叫File Watcher（文件监听器）。
在Windows上，VSCode用的是ReadDirectoryChangesW，Linux用的是inotify，macOS用的是FSEvents。这套机制设计得很好，正常规模的项目没问题，但一旦项目里文件数量过多（常见于node_modules、.git目录、虚拟环境、构建产物），监听器就会不堪重负。
具体表现是什么？文件监听的资源被大量消耗，某个文件的变化触发了一连串的事件，而这些事件又需要被分发到渲染进程和工作区扩展进程。如果前端进程处理不过来，就会出现“等待中”的现象。
在Linux环境（或者WSL、远程开发容器里），更典型的问题就是ENOSPC: System limit for number of file watchers reached。这是因为Linux的inotify默认就有上限，通常是65536，听起来挺大，但一个node_modules轻松就能超过这个数。VSCode检测到监听器无法建立，就会不断重试，每次重试都带有一段不可控的等待时间。
所以我通常把文件监听器当成第一嫌疑。只要你的项目文件夹里有巨量的嵌套目录，或者某个目录里文件特别多，就先从监听器角度排查。
1.3 “一直等待中”还可能是什么在拖后腿
除了File Watcher，还有一个经常被忽略的因素：自动保存机制与文件系统事件的碰撞。
VSCode默认的files.autoSave是off，但很多人装了一些代码格式化扩展，比如Prettier、ESLint，甚至有些主题扩展也会开启“保存时自动修复”之类的能力。一旦扩展监听到文件保存事件，就会开始执行额外的操作，比如重新格式化、检查lint规则、触发git diff计算。这在大型文件上是非常耗时的。
另一个因素是杀毒软件或者云盘同步工具。国内很多用户装了360、腾讯电脑管家之类的软件，它们会实时扫描被修改的文件。当VSCode保存一个文件时，杀软要先把文件读一遍，扫完毒再放行，整个过程可能在几百毫秒到几秒不等。如果项目文件特别大，比如一个几千行的JSON配置文件，那这个等待时间就会被拉得很长。
我印象最深的是有一次用户反馈，在公司的Windows电脑上，package-lock.json保存一次要等40多秒。后来发现是电脑上装了一个安全软件，把node_modules目录整个加进了实时监控范围，导致每次文件变化都要触发安全软件的全目录扫描。
所以，定位“等待中”这个问题，不能只看开发环境本身，还要看操作系统层面是否有额外干预。
2. 排查工具与定位方法
2.1 使用“开发人员工具”查看错误日志
当你已经确认卡顿集中在某个项目或某些操作上，下一步就是用VSCode自带的诊断工具把问题揪出来。
按Ctrl+Shift+P打开命令面板，输入Developer: Toggle Developer Tools，回车后会弹出一个类似浏览器开发者工具的窗口。切到“Console”标签页，然后去执行一次卡顿的文件操作（比如保存一个文件）。回来看Console里有没有出现红色的报错信息。
我这里列举几个我实际见过的报错，以及它们对应的含义：
Error: ENOSPC: System limit for number of file watchers reached：监听器数量达到系统上限，常见于Linux/WSL；如果是Windows，也有可能在某个虚拟磁盘映射上出现。Failed to watch file或者Error: EPERM: operation not permitted, watch：权限问题，可能是文件系统权限不允许VSCode建立监听。A system error occurred (EACCES: permission denied)：这个通常是文件本身没有写入权限，保存时等待，其实是操作系统拒绝写入。
在Console里看到这些报错，基本就能锁定方向了。不过有时候Console里报错的频率很高，刷屏刷得很快，我建议你先清空Console（点左上角那个禁止符号），再进行一次文件操作，这样更容易抓取到有效信息。
除了开发者工具，你还可以打开“输出”面板，命令面板输入View: Toggle Output，然后在下拉列表里选择“窗口”或者“扩展主机”。这里会记录Windows的日志以及扩展的启动和运行日志，有时候能发现某个扩展长时间占用CPU或者报错。
2.2 快速实验：在新窗口打开文件夹或禁用扩展
如果日志里没有明显报错，那就用排除法。
最简单的实验方式有两个：
第一个，用VSCode的命令行模式启动一个不带扩展的实例。直接在终端里执行：
code --disable-extensions --new-window 项目文件夹路径这个命令会打开一个全新的无扩展窗口。在无扩展窗口里重复之前卡顿的操作。如果不卡了，那说明问题出在扩展上。如果还是卡，那说明是VSCode核心或者系统层面的问题。
第二个，在“设置”里搜索files.autoSave，将它改成off，保存一下。再次进行文件操作。如果不卡了，那说明自动保存与某些扩展的保存后行为产生了阻塞。
我个人的习惯是先用--disable-extensions，因为它能一次性排除掉所有扩展因素，效率最高。有一次我排查一个“删除文件后一直在转圈”的问题，排查了半天，最后发现是一个叫“GitLens”的扩展在文件删除后触发了git影响的重新计算，而这个项目恰好是一个超大仓，计算影响范围花了十几秒。禁用扩展后立竿见影。
2.3 检查任务管理器：谁在CPU飙升
有时候“等待中”不是那种彻底的假死，而是界面操作响应慢。这时候可以打开操作系统的任务管理器（Windows）或者活动监视器（macOS），看哪个进程的CPU占用率异常。
VSCode本身有很多进程，比如主进程Code.exe、渲染进程、扩展宿主进程、语言服务器进程等。如果某一次文件操作卡顿时，某个node.exe进程的CPU瞬间冲到100%，那大概率是这个进程对应的扩展或者语言服务器在同步文件状态。
常见的元凶有：
ESLint：保存时全量校验TS Server（TypeScript语言服务器）：文件变化后重新编译整个项目的类型Python语言服务器（Pylance）：索引大型Python项目Git插件：文件变化后刷新git状态
看到哪个进程在CPU飙升，就对应去排查。最简单的方法是在VSCode里逐个禁用可能相关的扩展，直到找到罪魁祸首。
3. 完整解决步骤：从配置到环境逐个击破
3.1 调整文件监听与同步配置
如果确认是文件监听器的问题，直接打开settings.json进行配置。
按Ctrl+Shift+P，输入Open User Settings (JSON)，会打开一个JSON配置文件。在里面加上以下内容：
{ "files.watcherExclude": { "**/.git/objects/**": true, "**/.git/subtree-cache/**": true, "**/node_modules/*/**": true, "**/node_modules/**": true, "**/dist/**": true, "**/build/**": true, "**/target/**": true, "**/.idea/**": true, "**/__pycache__/**": true, "**/.venv/**": true, "**/venv/**": true } }这里面的含义是告诉VSCode：不要监听这些目录的变化。node_modules、dist、build、__pycache__这些目录，你根本不需要在编辑器里实时查看它们的变化，排除掉之后，文件监听器的负担能减少一大半。
但注意，这条配置只对VSCode自带的文件监听生效，并不能阻止扩展自己建立监听。所以如果你用了像search for files in node_modules之类的扩展，仍然会卡。我的建议是，同时把files.exclude也配置一下，让这些目录在文件树里也隐藏掉：
{ "files.exclude": { "**/node_modules": true, "**/dist": true, "**/build": true, "**/.git": true } }files.exclude会让这些目录在VSCode资源管理器里彻底不可见。虽然它不直接影响监听器，但可以防止一些扩展（尤其是代码导航类扩展）去索引这些目录。
如果你在Linux或WSL环境下遇到ENOSPC，除了上面的排除配置，还可以手动调高系统监听上限。在终端执行：
sudo sysctl fs.inotify.max_user_watches=524288 sudo sysctl fs.inotify.max_user_instances=1024这里我把max_user_watches设置成524288，也就是大约51万个。为什么选这个数？因为一个中大型项目的node_modules加上缓存文件很容易逼近6万个监听条目，而默认的65536只够一个项目用；拆到512K，基本可以满足同时打开两三个大型项目。如果你不想让修改在重启后失效，就把上面的命令写入/etc/sysctl.conf里。
3.2 处理远程环境与权限问题
现在很多开发者已经不在本地打开文件夹了，而是用Remote - SSH、WSL或者Dev Containers插件直接编辑远程机器上的文件。这时候的“增删改查文件一直等待”和本地本机完全是两码事。
远程卡顿的原因主要有三个：
网络延迟导致文件操作请求长时间阻塞。VSCode的远程模式并没有把整个远程文件系统拉到你本地，而是通过一个在远程机器上运行的“服务端”把文件内容转发过来。你新建一个文件，实际上是先发送一个创建请求给远程服务端，由服务端在远端创建文件，再同步返回结果。如果网络抖动，或者中间有跳板机，等待时间就可能非常长。
远程机器上的VSCode Server没有安装好。当你第一次连接远程机器时，VSCode会自动在远程机器的
~/.vscode-server目录下安装一个服务端。如果这个目录因为权限问题或者磁盘满导致无法写入，VSCode会一直处于连接状态，或者文件操作卡死。你可以试着清理远程机器上的~/.vscode-server目录，然后重新连接。远程机器的文件系统本身很慢。比如你在远程挂载了一个NFS、SMB之类的网络盘，然后在VSCode里操作这个网络盘上的文件，那速度会被网络盘本身的IO瓶颈限制住。
针对远程模式，我最常用的几个解决办法：
- 在远程机器上安装VSCode服务端时，确保
~/.vscode-server有可写权限。如果之前装过老版本，残留了旧的服务端文件，直接在终端里执行：
rm -rf ~/.vscode-server然后重新在VSCode里连接远程，它会自动安装最新的服务端。
- 如果网络不稳定，可以在VSCode的设置里增加远程超时时间。在
settings.json中添加：
{ "remote.SSH.connectTimeout": 30, "remote.SSH.remotePlatform": { "你的远程主机名": "linux" } }connectTimeout单位是秒，这里我设为30秒，默认的10秒在通过跳板机时不生产。实测下来，这个值设成30不会让连接变慢，反而能避开很多因为网络抖动导致的连接失败。
- 如果是WSL环境，有时候会因为Windows上的杀毒软件拦截了
wsl.exe与Linux虚拟机之间的通信，导致文件读写卡顿。解决办法是把C:\Windows\System32\wsl.exe添加到杀毒软件的信任列表，或者直接关闭对WSL目录（\\wsl$\...）的实时监控。
权限问题同样不能忽视。有些项目里某些文件是只读的，或者由其他用户创建，你当前维度的账户没有写入权限。你在VSCode里想修改这个文件，保存时VSCode会弹出一个提示，告诉你文件是只读的，可以选择“以管理员身份重新加载”或者“覆盖”。如果你没注意到这个提示，直接点了保存，VSCode会一直尝试写入，然后被系统拒绝，界面看起来就是“一直等待中”。
在Linux或macOS下，你可以先用终端检查文件权限：
ls -la 文件名然后用chmod或者chown调整权限，再回到VSCode里操作。
3.3 扩展冲突的排查与处理
前面提到了用--disable-extensions排除扩展因素，如果你找到了具体是某个扩展导致的问题，但又不想彻底卸载它，可以尝试修改它的配置，或者禁用它在特定场景下的自动操作。
以最常见的ESLint为例，如果你的项目非常大，而你在保存文件时ESLint会对整个项目做校验，那么等待时间就会非常长。你可以在settings.json里调整ESLint的运行时机：
{ "eslint.validate": ["javascript", "javascriptreact", "typescript", "typescriptreact"], "eslint.format.enable": false, "eslint.lintTask.enable": false, "eslint.workingDirectories": [] }关键是把eslint.lintTask.enable设为false，让ESLint只在编辑器打开单个文件时对单文件检查，不要保存时触发整个任务的lint。
另外，很多扩展会在“文件操作”时同步做很多事情。比如GitLens会在文件删除或重命名时刷新Git历史记录；Live Server会在文件保存时重新加载浏览器页面；REST Client会在响应文件变化时更新预览。这些扩展本质上都会把文件操作变成“串联等待链”。
我整理过一个扩展自查清单，遇到文件操作卡顿，你可以先挨个试：
- 禁用所有Git相关扩展（GitLens、Git History、Git Blame等）
- 禁用所有主题和图标主题，因为这些扩展可能会在文件数变化时重绘UI
- 禁用所有与文件导航相关的扩展（比如Project Manager、SFTP）
- 禁用所有自动保存格式化扩展（如Prettier）
每次禁用一个，然后重复一次卡顿操作，记录是否改善。用这种二分法，一般不出十次就能锁定目标。
4. 常见问题速查表与独家避坑经验
4.1 不同卡顿场景对照表
根据我长期观察和实战积累，把“增删改查文件一直等待中”拆成几个典型场景，每个场景对应的原因和解决办法都不同，下面用表格列出来，方便你对照着处理。
| 卡顿场景 | 典型表现 | 最大概率原因 | 首选解决办法 |
|---|---|---|---|
| 新建文件一直等待 | 按新建快捷键后，文件树卡片不出现，或者出现后没有高亮可输入状态 | 文件监听器尚未释放资源 | 设置files.watcherExclude，排除node_modules、dist等大目录 |
| 删除文件一直等待 | 删除后文件名短暂残留，然后一直转圈 | 扩展（如GitLens）引发了删除后的二次操作 | 使用--disable-extensions定位原因，再针对性处理 |
| 保存文件一直等待 | 保存后状态栏显示“正在 save”，长时间不消失 | 自动保存与扩展保存后行为冲突 | 设置files.autoSave为off，再排查ESLint/Prettier |
| 重命名文件一直等待 | 重命名后文件树和编辑器标题栏同步慢 | 大仓索引重建 | 关闭文件索引扩展，设置files.exclude隐藏无关键目录 |
| 远程文件操作等待 | 在Remote-SSH时新建/删除文件需要数秒 | 远程服务端卡顿或网络延迟 | 清理~/.vscode-server，增大remote.SSH.connectTimeout |
| 打开特定文件等待 | 只对某个大文件卡，其他正常 | 文件本身太大，如MB级别的JSON、日志 | 提高files.maxMemoryForLargeFilesMB，或使用大文件扩展 |
| 整个VSCode无响应 | 鼠标点击任何地方都没反应 | 主进程被某个插件阻塞 | 看任务管理器，结束对应node.exe进程，或重启VSCode |
这个表格我把处理思路分成了“配置”“扩展”“环境”三条路线。遇到问题时先沿着一条路线走，不要同时改多个变量，否则你很难知道到底是哪一步救了你的项目。
4.2 我踩过的坑和最后的杀手锏
卡顿问题处理多了，我总结了一套“保命步骤”，专门用来处理那些配置调了、扩展关了、还是卡得离谱的情况。
第一个保命步骤：清理工作区存储。
VSCode对每个工作区都会保存一份缓存，里面包含一些状态数据、UI状态、以及文件监视器的历史记录。如果一个项目曾经非常庞大，后来你删除了一堆文件，但缓存里还保留着旧的文件树状态，就可能导致后续的文件操作异常。解决方案是把工作区对应的缓存文件夹删掉。
在Windows上，路径是：
C:\Users\你的用户名\AppData\Roaming\Code\User\workspaceStorage在Linux上：
~/.config/Code/User/workspaceStorage删掉这个目录里的某个文件夹（怎么判断哪个文件夹对应哪个项目？你可以直接打开文件夹，里面有一些以file://或vscode-remote://开头的文件夹，对比一下路径就能认出来）。删除后重启VSCode，它会重新初始化该工作区的状态。
第二个保命步骤：用命令行验证文件操作是否正常。
如果VSCode里新建、删除、保存都卡，但你在终端里用touch、rm、cat这些命令操作完全没有延迟，那说明VSCode本身和操作系统之间的通信出问题了。这时候最简单的做法是退出VSCode，重命名配置文件夹：
mv ~/.config/Code ~/.config/Code.bakWindows上对应是%APPDATA%\Code。然后重新启动VSCode。这样会用默认配置启动一个“全新”的VSCode，你的扩展和配置全部变成了空白。如果你发现卡顿消失了，再逐步导入你原来的配置（比如从Code.bak里复制部分设置）。这个方法相当于“重置VSCode”，能解决很多深层次的配置损坏问题。
第三个保命步骤：注意文件路径中的网络盘和压缩文件。
我曾经在一个项目里反复出现“读取文件一直等待”，后来发现项目的根目录是一个压缩包的映射盘（比如用WinRAR解压后没有真正释放到硬盘，而是直接双击打开压缩包，把压缩包路径当作工作区）。VSCode在解析压缩包路径时，每次都会去压缩包内查询文件，速度极慢。解决办法很简单：把压包释放成普通文件夹再打开。
另外，如果你把项目放在C:\Users\用户名\OneDrive\文档这种云同步目录下，每一次文件保存都会触发云盘上传，再加上云盘本身的文件监听，会出现“双重监听”的卡顿。遇到这种情况，我强烈建议把项目移出云同步目录。
4.3 如何一劳永逸地规避文件操作卡顿
工具用久了，会慢慢形成自己的一套配置习惯。针对文件操作卡顿，我这几年已经形成了一套固定的组合拳，分享给大家。
明确哪些目录需要监听。能用
files.watcherExclude排除的，就坚决排除。我的默认排除列表已经包括node_modules、dist、build、.git、__pycache__、.venv、target。允许VSCode自动保存，但降低保存后副作用。我这里说的自动保存，是VSCode官方提供的
files.autoSave选项，我通常设为afterDelay，并把files.autoSaveDelay调成1000毫秒。这样保存操作会合并到一次事件里，而不是每次敲击键盘都触发一次文件写入。但与此同时，我会把Prettier、ESLint的保存时格式化功能关掉，避免保存后连锁反应。
{ "files.autoSave": "afterDelay", "files.autoSaveDelay": 1000, "editor.formatOnSave": false, "editor.codeActionsOnSave": {} }安装扩展前先搜一下它的口碑。很多“文件操作卡顿”其实是某几个流行扩展在后台长期吃资源的后果。我现在装扩展之前，都会在它的扩展页面看看最近几个版本是否有人反馈文件监听的问题。例如曾经有一个非常流行的“File Utils”扩展，老版本在每次文件重命名后都会扫描整个工作区，后来升级修复，但我短时间内遇到过三家公司的同事都在用老版本出事。
及时升级VSCode和扩展版本。VSCode官方在文件监听方面做了很多优化，比如加入了“文件监听重用”机制，还有
files.useExperimentalFileWatcher选项。虽然后者在新版本中已经废弃，但官方对文件系统事件的处理越来越高效。如果你还在用老版本，建议先升级到最新稳定版。
写在最后的个人体会
折腾了这么多次文件卡顿问题，我最大的体会是：VSCode本身是一个非常稳定的编辑器，绝大多数“一直等待中”并不是它的Bug，而是我们给它的任务太重了——要么是项目里塞了太多不该被监听的文件，要么是扩展在背后做了太多我们不需要的事，再不然就是远程环境或者杀毒软件在中间捣乱。
我在实际处理问题时，已经养成了一个习惯：一旦感觉到文件操作有迟滞，先不急着改代码，而是花五分钟把监听的目录捋一遍、把最近常驻的扩展过一遍。很多时候，问题就藏在那些你曾经为了解决某个需求而随手装上的扩展和配置里。把这个习惯养成之后，你会发现VSCode能一直保持刚装完时的轻快手感，增删改查文件再也不会转圈等待。希望这篇内容能帮你也达到这个状态。
