sublime text 卡顿主因是 index_files 后台扫描，尤其遇 node_modules 或 .git 目录；关掉它（"index_files": false）可立解，但禁用符号跳转；推荐用项目级 folder_exclude_patterns 精准排除大目录，兼顾性能与功能。
确认是不是 index_files 在后台疯狂扫描
Sublime 的 index_files 默认开启，一打开含 node_modules 或 .git 的项目，它就开始同步遍历所有文件——不是“搜索慢”，是边敲字边干着比 npm install 还重的活。CPU 拉满、光标卡顿、方向键失灵，基本就是它在作祟。
验证方法：完全退出 Sublime，按住 Ctrl（Win/Linux）或 Cmd（macOS）再双击启动。如果这时 Ctrl+P 丝滑无延迟，问题就锁定在索引行为。
- 最快见效：打开
Preferences → Settings，在右侧用户设置 JSON 中加一行"index_files": false，然后必须完全退出再重启（仅重载设置无效） - 副作用明确：
Ctrl+R（跳转符号）、F12（Go to Definition）、Find All References全部失效；但Ctrl+P（文件名模糊匹配）和Ctrl+Shift+F（文本内容搜索）仍可用 - 别在全局关死——如果你日常要写 JS/Python 工程，建议往下看更平衡的方案
用 folder_exclude_patterns 精准排除大目录
保留 Ctrl+P 和符号跳转能力，但让索引器“假装看不见”那些脏目录。关键是要写进项目级配置（.sublime-project），而不是改全局设置，避免影响其他小项目。
操作路径：菜单栏 Project → Edit Project，在 folders 块里补上：
{
"folders": [
{
"path": ".",
"folder_exclude_patterns": ["node_modules", "__pycache__", ".git", "dist", "build", "logs"],
"file_exclude_patterns": ["*.log", "*.tmp", "*.zip", "*.tar.gz"]
}
]
}
- 这个配置对 LSP 插件也生效，比如
pylsp不会再扫描node_modules里的 Python 文件 - 注意：
folder_exclude_patterns只作用于项目根目录下的子目录；如果依赖在深层路径（如src/lib/node_modules），得靠 LSP 插件自身的initializationOptions单独配 - 用
subl .命令行打开项目时，确保当前目录下有.sublime-project文件，否则配置不加载
排查 plugin_host 进程是否被插件拖垮
当 plugin_host 持续占满一个 CPU 核，基本可断定是某个插件失控。常见元凶包括 LSP-pyright、SublimeLinter、GitGutter、Terminus——它们不是“装上就跑”，而是持续 fork 子进程、响应输入事件、加载 AST。
- 第一步：命令行启动
subl -safe-mode，若 CPU 正常，说明问题出在插件 - 第二步：打开控制台
Ctrl+`，重点扫三类线索：重复报错、starting循环日志、高频 Pythontraceback - 第三步：逐个禁用可疑插件（优先动
LSP类、GitGutter、AutoFileName），观察plugin_host的 CPU 变化 - 补充技巧：某些插件支持“按项目启用”，比如 GitGutter 可设
"enabled": false在项目配置里，比全局卸载更灵活
别忽略异常文件或编码导致的隐性负载
Sublime 遇到无法识别编码的文件（比如 UTF-8 BOM 错乱、混合二进制内容的日志），可能反复尝试解析失败，触发高频重试逻辑；或者误把 .zip、.so 当文本文件加载，直接拉满内存和 CPU。
- 临时验证：关闭所有标签页，只留一个空文件，看 CPU 是否回落；再逐个打开最近编辑过的文件，定位异常源
- 批量清理：在项目设置中补上
"file_exclude_patterns": ["*.zip", "*.so", "*.dll", "*.exe"]，尤其适合混有构建产物的前端或嵌入式项目 - 超大文件（>10MB）别硬扛：日志、dump、数据库导出文件，改用
less、vim -u NONE或专用查看器，Sublime 不是为这类场景设计的
真正麻烦的从来不是单点配置，而是多个排除规则叠加后互相干扰——比如项目配置里写了 folder_exclude_patterns，但某个 LSP 插件又在初始化时强行覆盖了路径白名单。这种时候，得打开控制台盯着 Python traceback 里具体哪一行在读哪个路径，才能揪出根因。
