多开Sublime窗口卡顿的根源是plugin_host单进程共用导致内存泄漏，需停index_files、清Cache/Index、禁用LSP/GoSublime自动诊断三步解决。
多开 Sublime 窗口后输入卡顿，不是“多个窗口抢资源”，而是 plugin_host 进程被多个窗口共用且未隔离，插件（尤其是 LSP、GoSublime、SublimeLinter）在后台持续分析、重复加载缓存、goroutine 泄漏叠加导致内存不释放——关掉 index_files、清空 Cache/Index、禁用跨窗口插件自动诊断，三步做完，卡顿基本消失。
为什么多开窗口会让 plugin_host 内存飙到 1.5GB+
Sublime 的 plugin_host 是单进程托管所有 Python 插件的，无论你开几个窗口，它们都往同一个 plugin_host 里塞任务。LSP 为每个窗口启动语言服务器？不，它默认复用；GoSublime 的 margo goroutine 在第一个窗口启动后就常驻，第二个窗口打开时又触发一次 AST 加载，引用没清理，内存就叠着涨。
常见表现：
-
plugin_host占用内存持续上升，重启一个窗口没用，必须杀掉整个进程 - 按 Shift+Tab 或中文输入法切换时，光标卡住 1–2 秒，状态栏输入法图标转圈
- Ctrl+P 搜索延迟明显，甚至返回空结果（索引已错乱）
必须停掉 index_files，否则删缓存也白清
index_files 默认为 true，一开多窗口，每个窗口都在后台争抢扫描同一项目下的 node_modules，plugin_host 就在那儿反复 stat() + read() + 解析，CPU 拉满，内存碎片化。这不是“慢”，是编辑器在你打字时干着比 webpack 还重的活。
操作路径：
- Preferences → Settings，在右侧用户设置中加：
"index_files": false - 必须彻底退出 Sublime：Windows 查任务管理器确认
sublime_text.exe和plugin_host.exe都消失；macOS 用活动监视器确认Sublime Text和plugin_host进程全无 - 仅重载设置或只关窗口无效——索引上下文已固化在进程里
删 Cache 和 Index 目录前，先确认进程真死了
Windows 用户最常漏掉 %LOCALAPPDATA%\Sublime Text\Cache，这里藏了 LSP 插件最顽固的编译缓存（比如 pyright 的类型快照），删 %APPDATA% 下的 Cache 不管用。而 Index 目录（和 Cache 同级）存的是全文搜索和符号跳转的底层数据库，损坏后 Ctrl+R、Ctrl+P 就变“假响应”。
删之前务必确认：
- Windows：任务管理器搜
sublime_text.exe和plugin_host.exe，全部结束 - macOS：活动监视器查
Sublime Text和plugin_host，强制退出 - Linux：
pkill -f "sublime_text"，再ps aux | grep sublime确认无残留 - 删完整目录，不是清空子文件；删完别急着开，等 3 秒再双击启动
LSP 和 GoSublime 要单独关自动诊断，否则 index_files = false 也压不住
即使关了 index_files，LSP 插件仍会为当前打开的文件自动启动语言服务器并加载 AST；GoSublime 的 margo 默认开启包预加载（NoPreloading: false），一开多窗口，每个窗口都触发一次 go list 扫描，内存直接叠加上去。
实操建议：
- LSP：打开
Packages/User/LSP.sublime-settings，加："enabled": false（全局关），或在项目配置里用"settings": {"lsp_disabled": true} - GoSublime：在
Packages/User/GoSublime.sublime-settings中设："margo": {"NoPreloading": true} - 别信“插件自己会回收”，GoSublime 的
oom.go显示，它靠runtime.NumGoroutine()监控，但泄漏常发生在 goroutine 已退、引用还在的边缘情况
真正麻烦的不是多开窗口本身，而是 Sublime 没做插件进程隔离，所有窗口共享同一套缓存上下文和 goroutine 池——你删一次缓存能爽两天，但只要 index_files 还开着、LSP 还在后台扫 node_modules，三天后内存又回到 1.2GB。动手前先杀干净进程，比调一百行配置都管用。
