快速确认是否为index_files导致CPU过高：完全退出Sublime（含托盘进程），按住Ctrl/Cmd双击图标启动（跳过索引与插件），若立即流畅则基本锁定index_files或插件问题；仅重载设置无效，必须彻底退出进程。
怎么快速确认是不是 index_files 在抢 CPU
Sublime Text 启动后 CPU 持续 70%~100%，八成是 index_files 在后台扫描 node_modules、.git、dist 这类目录。它不是“慢”，而是编辑器在你敲字时同步 stat() 几万文件、建跳转索引，CPU 核心直接被占满。
验证方法很简单：完全退出 Sublime（包括系统托盘进程），再按住 Ctrl（Windows/Linux）或 Cmd（macOS）双击图标启动——此时会跳过项目索引和插件加载。如果操作立刻丝滑，基本锁定是 index_files 或插件问题。
- 仅重载设置或 Ctrl+R 重启无效：旧索引上下文已固化在内存里，必须彻底退出进程
-
index_files关闭后，内存常从 1GB+ 直降到 200MB 左右 - 副作用明确：
Ctrl+R（跳转定义）、F12、Find All References全部失效；但Ctrl+P（文件名搜索）和Ctrl+Shift+F（文本搜索）不受影响
如何用 folder_exclude_patterns 精准排除而不全局关索引
如果你仍需要 Ctrl+P 或 Ctrl+R 在 src/、app/ 下精准跳转，就别一刀切关 index_files。改用项目级 folder_exclude_patterns 更稳妥——它让 Sublime 彻底忽略指定目录，连侧边栏都不显示，也不触发任何扫描。
操作路径：Project → Edit Project，在 JSON 的 folders 块中补全：
{
"folders": [
{
"path": ".",
"folder_exclude_patterns": ["node_modules", "__pycache__", ".git", "dist", "build", "logs"],
"file_exclude_patterns": ["*.log", "*.tmp", "*.zip"]
}
]
}
-
folder_exclude_patterns只作用于项目根目录下的子目录；若src/lib/node_modules这类深层路径也要排除，得靠 LSP 插件自身的initializationOptions单独配置 -
file_exclude_patterns主要防误搜，对 CPU 影响小，但能减少Ctrl+Shift+F扫描范围 - 排除后，
plugin_host进程的 CPU 波动会明显收敛，尤其在保存或切换标签时
plugin_host 高 CPU 怎么定位到具体插件
plugin_host 是 Sublime 运行 Python 插件的独立进程。一旦它持续吃满一个 CPU 核，基本可断定是某个插件失控了——比如 LSP 服务器反复崩溃重启、SublimeLinter 在大文件上实时跑校验、或者 GitGutter 持续轮询状态。
快速验证：subl --safe-mode 启动，如果 CPU 正常，说明问题出在插件。接着分步排查：
- 打开控制台（
Ctrl+`），重点看有没有重复报错、starting...循环日志，或高频Python traceback - 高频嫌疑插件：
LSP-pyright、LSP-eslint、SublimeLinter、AutoFileName、GitGutter、Terminus - 检查 LSP 客户端配置：避免写
"scopes": ["*"]，应限定为"source.python"或"source.ts"；用Ctrl+Alt+Shift+P查当前文件真实 scope，别凭感觉配
大文件加载卡死时怎么立刻恢复滚动
文件已打开但界面冻结？别等、别重启，直接打断正在运行的渲染链。Sublime 卡死不是因为内存不够，而是语法高亮逐行正则匹配、自动换行反复计算断点、索引线程全文件扫描三者叠加导致 UI 线程被锁死。
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Set Syntax: Plain Text回车——立刻终止所有.sublime-syntax解析 - 再输
View: Toggle Line Numbers关行号，避免为百万行生成 DOM 节点 - 右下角点击当前语法名（如显示
JSON或Log），选Open all with current extension as… → Plain Text，防止下次同后缀文件重蹈覆辙 - 顺手执行
View → Word Wrap → Off，否则超长日志行会让渲染引擎反复计算软换行位置，拖慢十倍
真正难处理的不是“怎么开”，而是“怎么让它别当这是个要编辑的文件”——很多配置项（比如 large_file_size_limit）只对后续新打开的文件生效，已卡住的实例必须手动干预渲染链。
