禁用插件不重启窗口无效，真正耗内存的是语法解析、语言服务和文件监听；需完全退出VSCode并重开，配准files.watcherExclude，大JSON改用纯文本模式或专用命令行工具。
大文件查看插件冲突本身不是直接原因，真正吃内存的是它们触发的语法解析、语言服务和文件监听行为——禁用插件不重启窗口等于没做。
为什么禁用 Prettier/JSON 插件后仍 OOM
VSCode 的 prettier、json-language-features、auto-close-tag 等插件在打开大 JSON/TS/JS 文件时会强制全量 parse 整个内容，对几百 MB 文件，V8 堆瞬间打满。禁用插件只是阻止下次加载，当前已运行的 Extension Host 进程仍驻留并持续持有内存。
- 看到“已禁用”不代表进程退出——必须完全关闭 VSCode 窗口（macOS 要退出菜单栏图标），再重新打开项目
- 禁用后仍卡死？按
Ctrl+Shift+P运行Developer: Open Process Explorer，找extensionHost行，右键复制命令行，确认是否还含prettier或jsonc关键词 - 别信
Developer: Show Running Extensions显示的“0MB”，它只估算，不准；真实 RSS 看Open Process Explorer的 Memory 列
files.watcherExclude 配错等于放任监听器爆内存
VSCode 默认用 chokidar 监听整个工作区，node_modules 里几万个文件每个都注册一个 inotify 句柄，Linux/macOS 上几乎不回收，内存线性上涨。这不是插件质量问题，是系统级资源耗尽。
- 必须写在项目根目录的
.vscode/settings.json，全局设置在多工作区下 100% 失效 - 规则必须带双星号和尾部斜杠：
"**/node_modules/**": true✅，"node_modules/**"❌，"**/node_modules"❌ - Python 项目务必加：
"**/.venv/**": true、"**/venv/**": true；pnpm 用户补："**/node_modules/.pnpm/**": true -
search.exclude和files.watcherExclude不是一回事：前者只跳过搜索结果，后者才真正阻止内核句柄注册
打开大 JSON 文件的正确姿势
VSCode 默认把 JSON 当语言模式处理，会启动折叠、验证、补全等全套服务。几百 MB 文件根本扛不住——这不是性能问题，是设计边界问题。
- 别双击打开，改用终端命令：
code --disable-extensions --disable-gpu --max-memory=4096 ./huge.json - 打开后立刻按
Ctrl+K Ctrl+M（Win/Linux）或Cmd+K Cmd+M（Mac），输入plaintext回车，切换为纯文本模式，跳过所有语法解析 - 检查
files.associations，避免把*.json错误映射到jsonc；jsonc解析器更慢，因为它要扫描注释边界 - 想保留结构化查看？换专用工具：
jq -r '.key' huge.json或rg "pattern" huge.json，比 VSCode 快且稳
Extension Host 进程泄漏难定位的真相
多个插件共享同一个 Extension Host 进程空间，一旦某个插件没调用 dispose() 清理监听器、或缓存未 clear()，内存就只增不减。你看到的“500MB 卡住”，往往不是瞬时峰值，而是缓慢爬升后彻底僵死。
- GitLens、
esbenp.prettier-vscode、ms-python.python是高频泄漏源，尤其在打开大日志、大 JSON 后 - 某插件显示
N/A内存值？极大概率是内部泄漏导致 V8 无法统计，直接禁用验证 - 禁用后内存不降？旧 PID 还在跑。用
ps aux | grep -i "pyright\|tsserver\|prettier"找 PID，kill -9 [PID]强杀 - 远程开发（SSH）场景下，崩溃八成发生在远端 Node 进程，需单独配置远端
NODE_OPTIONS=--max-old-space-size=4096
真正难处理的从来不是单个插件，而是多个语言服务（如 TypeScript + Python + JSON）在同一个 Extension Host 进程里互相干扰——它们共用堆，但各自缓存策略不同，泄漏点交叉隐藏。手动 kill PID 和严格配 files.watcherExclude 是目前最可靠的组合拳。
