Extension Host内存卡住不释放的唯一有效解法是通过"extensions.experimental.affinity"配置隔离插件进程，并配合VSCODE_EXTENSION_HOST_ENV环境变量注入--max-old-space-size参数，且必须彻底退出VSCode后重启才能生效。
Extension Host 内存卡住不释放，怎么调上限
VS Code 的插件运行在独立的 Extension Host 进程里，它本身是 Node.js 进程，但**没有默认内存上限**——V8 堆会不断增长直到系统 OOM 或被杀。你看到“GitLens 占 600MB”“Prettier 一直不降”，不是插件写得差，而是这个进程没设限，泄漏也收不回来。
-
Extension Host不读NODE_OPTIONS，也不认--max-old-space-size启动参数（那是给终端里手动跑的 Node 进程用的） - 唯一有效方式：通过 VS Code 的
affinity配置，把它隔离成一个可单独调参的子进程 - 在用户或工作区
settings.json中加：
"extensions.experimental.affinity": {
"ms-python.python": 1,
"esbenp.prettier-vscode": 1,
"gitlens": 1
}
这个配置会让指定插件在独立子进程中运行，之后你就能对每个子进程单独加内存限制——但注意：VS Code 官方没暴露直接设堆大小的 UI 或 setting 项，所以实际要靠环境变量注入。
- Windows：启动 VS Code 前，先运行
set VSCODE_EXTENSION_HOST_ENV=--max-old-space-size=3072 - macOS/Linux：启动前运行
export VSCODE_EXTENSION_HOST_ENV=--max-old-space-size=3072 - 该变量只影响新启的
Extension Host子进程，旧进程需完全退出 VS Code 再重开才生效
为什么改了 typescript.tsserver.maxTsServerMemory 没用
这个 setting 只管 TypeScript 语言服务（tsserver），和 Extension Host 是两个进程。哪怕你把 maxTsServerMemory 设成 4096，GitLens、ESLint、Python 插件的内存照样不受控。
-
typescript.tsserver.maxTsServerMemory和javascript.tsserver.maxTsServerMemory是 tsserver 自己解析的参数，不是 Node 启动参数 - 它们只对 TS/JS 语言功能生效，不影响插件逻辑、文件监听、格式化等行为
- 如果你发现插件内存高但 tsserver 内存低，说明问题不在语言服务，别在这儿调参数
禁用插件后内存还在涨，怎么办
禁用插件 ≠ 杀掉对应进程。Extension Host 进程是复用的：你禁用 GitLens，它的监听器可能还在跑；重启窗口也不一定清掉旧 PID，尤其 Windows 上残留很常见。
- 必须执行 Developer: Show Running Extensions（Ctrl+Shift+P），看每个插件右侧显示的「内存估算」是否真降了
- 如果没降，打开 Developer: Open Process Explorer，找到
Extension Host对应 PID，在终端里手动kill -9 [PID] - 再关掉整个 VS Code 窗口（不是 Reload），重新用
code --disable-extensions .启动，验证基线内存 - 逐个启用插件，每启一个就刷新
Show Running Extensions，定位真实泄漏源
远程开发时 Extension Host 内存爆了，能调吗
不能。远程场景下，Extension Host 默认跑在本地，但部分插件（如 Python、Remote-SSH 自身）会把子进程推到远端。这时候你本地设的 VSCODE_EXTENSION_HOST_ENV 对远端无效。
- 远端插件子进程（比如
pyright、eslint-server）走的是remote.SSH.remoteServerEnv注入的VSCODE_NODE_OPTIONS - 想控远端插件内存，得在远程工作区的
.vscode/settings.json里配：
"remote.SSH.remoteServerEnv": {
"VSCODE_NODE_OPTIONS": "--max-old-space-size=2048"
}
⚠️ 改完必须彻底断开远程连接（Close Remote Connection），再重新 Connect，否则旧进程还在。
真正难调的从来不是数字本身，而是搞清哪个进程在吃内存、谁在读哪个环境变量、改了要不要重启哪一层——漏掉任意一环，--max-old-space-size=8192 就只是安慰剂。
