sublime text无法直接查看单个插件内存占用，需通过subl --safe-mode验证插件影响，再结合控制台日志、逐禁用lsp/sublimelinter等高耗插件、配置项目级folder_exclude_patterns排除node_modules等目录，并清理cache/index目录来定位和解决内存问题。
Sublime Text 没有内置插件内存监控功能
直接在 Sublime Text 里查某个插件占了多少 MB 内存，这件事本身就不支持——plugin_host 进程不暴露各插件的独立内存用量，也没有类似 VSCode 的 Developer: Open Process Explorer 那样的可视化内存剖面工具。
你看到的内存飙升，永远是整个 plugin_host 进程的总 RSS（比如从 200MB 跳到 1.2GB），但无法靠 Sublime 自身日志或设置项反推出「LSP-pyright 占了 700MB」这种结论。
怎么确认是哪个插件在吃内存
核心逻辑是「排除法 + 行为观察」，不是「读数法」：
- 先运行
subl --safe-mode（Windows/macOS/Linux 均支持），完全绕过所有插件启动。如果内存回落到 200MB 以内，说明问题确实在插件层 - 打开
View → Show Console，重点盯这些线索：
— 反复出现的starting LSP server、restarting...
— 大量Python traceback或ImportError（尤其来自LSP、SublimeLinter、GoSublime） - 进
Preferences → Package Control → Disable Package，优先禁用：
— 所有以LSP-开头的（如LSP-pyright、LSP-typescript）
—SublimeLinter及其 linter 插件（如SublimeLinter-flake8）
—GitGutter（虽轻量，但在大仓库中会持续 polling） - 每次禁用后，必须彻底退出 Sublime（任务管理器/活动监视器确认
sublime_text.exe和plugin_host进程已消失），再重启观察内存峰值
folder_exclude_patterns 比禁用插件更关键
很多用户禁掉 LSP 后内存仍居高不下，根本原因不是插件本身，而是它扫描的目录——node_modules、dist、.git 这类目录只要在项目里，LSP 就可能无视 "index_files": false 自行加载文件元数据，瞬间拉高内存。
真正起效的是项目级排除，且必须写进 .sublime-project 文件：
{
"folders": [
{
"path": ".",
"folder_exclude_patterns": ["node_modules", "dist", "build", ".git", "logs"]
}
]
}
注意：
— "index_files": false 只停 Sublime 自带索引，LSP 类插件根本不认这行
— 排除规则必须写在项目配置里，用户设置中的 folder_exclude_patterns 对 LSP 无效
— 禁用插件后若没清理 Data/Cache/ 和 Data/Index/ 目录，旧索引缓存仍驻留内存
为什么你看到的「内存没降」可能是假象
Sublime 的内存释放机制很保守：即使关掉所有插件、清空缓存，plugin_host 进程的 RSS 也可能维持在高位数分钟，这不是泄漏，而是 Python 解释器的内存管理策略（例如 malloc 不主动归还给系统）。
判断是否真解决，看两个指标：
— 启动后 5 分钟内内存是否稳定在 300MB 以下（非瞬时峰值）
— 切换大项目时，plugin_host 是否不再出现持续上涨、卡顿、崩溃
真正的瓶颈往往不在「装了什么插件」，而在「项目里有什么目录」和「插件是否被允许扫描它们」——这点比插件列表本身更难察觉，也更容易被忽略。
