VSCode拖拽卡顿主因是插件在onDidCreateFiles等事件中同步执行重操作；可通过Developer: Open Process Explorer定位高内存插件，禁用GitLens缓存、ESLint即时检查及Prettier无配置格式化，并配置files.watcherExclude和inotify限制来优化。
拖拽文件进VSCode卡顿，基本是插件在监听路径时抢了主线程
VSCode本身对拖拽操作的处理很轻量，真正卡住的环节几乎都发生在“文件落盘后触发的扩展响应”——比如GitLens自动扫描新文件历史、ESLint立刻开始解析、Prettier尝试格式化未保存内容。这些动作默认是同步或高优先级执行的，一旦某个插件注册了onFileSystem或onDidCreateFiles这类事件，拖一个大文件或整个文件夹进来，它就可能卡住UI线程几秒。
用Developer: Open Process Explorer看谁在吃拖拽后的内存
拖拽完成后立刻按Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），运行Developer: Open Process Explorer：
- 展开
extensionHost节点，观察“Memory”列：刚拖完文件后RSS突然飙升到300MB+且不回落的插件，就是嫌疑对象 - 重点关注
eamodio.gitlens、dbaeumer.vscode-eslint、esbenp.prettier-vscode——它们会在onDidCreateFiles事件里做全量分析或缓存预热 - 如果
gitlens的RSS持续高于400MB，大概率是它在后台构建新文件的符号索引，尤其当文件夹含.git子模块时
禁用前先关掉插件的“自动响应”开关
很多卡顿不是插件本身重，而是它默认对任何新文件都立刻干活。改.vscode/settings.json能立竿见影：
-
"gitlens.advanced.caching.enabled": false：停掉GitLens对新增文件的自动缓存，拖100个文件也不会卡 -
"eslint.run": "onSave"：让ESLint别一拖进来就检查，等你手动保存再跑 -
"prettier.requireConfig": true：避免Prettier对没配.prettierrc的临时文件强行格式化 - 加
"files.watcherExclude"排除**/node_modules/**和**/dist/**，否则拖拽触发的文件事件会层层穿透到这些目录，监听器直接爆表
拖拽卡顿还可能是文件监视器被撑爆
VSCode底层用chokidar监听文件系统变化，而拖拽本质是大量create事件涌入。如果files.watcherExclude没配全，或Linux上inotify句柄不够，就会卡在事件队列里：
- 检查
cat /proc/sys/fs/inotify/max_user_watches，低于524288就执行echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches -
files.watcherExclude必须用双星号："**/node_modules/**"才有效，写成"node_modules"或"*/node_modules/*"都会失效 - 改完配置后必须关闭整个VSCode窗口再重新用
code .打开，只点Reload Window不会重载监听器
Developer: Open Process Explorer是唯一能实时看到插件在那一刻真实行为的工具。 
