Tabnine内存居高不下是因为默认预加载大模型且进程常驻，关闭tabnine.experimentalAutoDownload和experimentalPreloadModel并彻底重启VSCode可将RSS从800MB+降至120MB。
Tabnine 插件在 VSCode 中 RSS 常驻超 600MB，不是它“卡了”，而是默认启用后台模型预加载——关掉 tabnine.experimentalAutoDownload 并禁用 tabnine.experimentalPreloadModel，内存能从 800MB+ 直降到 120MB 左右。
为什么 Tabnine 内存不随关闭文件下降
Tabnine 不是传统插件，它启动时会拉起独立的 tabnine-binary 进程，并默认预加载完整语言模型（尤其 Python/TS 模型超 500MB）。这个进程注册了 onStartupFinished，禁用插件后仍常驻 Extension Host，直到窗口完全重启。
常见错误现象：
- 禁用 Tabnine 后
ps aux | grep tabnine仍能看到子进程 - Developer: Show Running Extensions 显示 Tabnine 内存占用 > 600MB，且不随关闭编辑器标签变化
- code --status 中
Extension HostRSS 居高不下，tabnine-binary占用 CPU 持续 > 40%
实操建议：
- 打开命令面板（
Cmd+Shift+P/Ctrl+Shift+P），执行Preferences: Open Settings (JSON) - 在
settings.json中添加以下两项并保存：
{
"tabnine.experimentalAutoDownload": false,
"tabnine.experimentalPreloadModel": false
}
这两项必须同时设为 false；只关一个，另一个仍会触发模型加载。
禁用后必须彻底重启窗口才生效
VSCode 不会终止已启动的 tabnine-binary 进程，哪怕你右键禁用了插件。它会继续运行、监听、缓存 token，RSS 不释放。
正确操作步骤：
- 先执行
Developer: Show Running Extensions，确认 Tabnine 状态为 “Disabled” - 关闭当前所有 VSCode 窗口（macOS 要点击菜单栏
Code → Quit Visual Studio Code） - 重新打开项目（不是
Developer: Reload Window） - 打开终端，运行
ps aux | grep -i tabnine，确认无残留进程
如果仍有输出，手动杀掉：kill -9 [PID]。注意：不要 kill Extension Host 主进程，只杀 tabnine-binary 子进程。
替代方案：用“仅聚焦时激活”模式保功能低开销
如果你仍需要 Tabnine 的补全能力，但不想它全天候吃内存，可启用按需加载策略：
- 在
settings.json中加一行："tabnine.experimentalOnFocusOnly": true - 该配置会让 Tabnine 只在当前编辑器获得焦点时启动模型，失去焦点后 30 秒自动卸载
- 配合前两项
false设置，实测开启补全时 RSS 峰值约 280MB，闲置时回落至 90–110MB - 注意：首次聚焦时会有 1–2 秒延迟，这是模型冷启动所致，属正常
别依赖 UI 开关——Tabnine 设置页里的 “Enable Tabnine” 滑块只控制补全开关，不控制模型加载行为，必须改 JSON 配置才真正生效。
最易被忽略的一点：Tabnine 的内存泄漏常和 files.watcherExclude 冲突。如果你已配了 "**/node_modules/**": true，但没关 tabnine.experimentalPreloadModel，它仍会尝试扫描 node_modules 中的 JS/TS 文件来优化训练数据——这会导致 inotify 句柄暴涨，间接推高 Extension Host 内存。所以配置顺序很重要：先关模型加载，再调监听范围，最后重启。
