Sublime Text 是单线程应用，所有核心逻辑运行于主线程，无法原生利用多核CPU；所谓“多核优化”仅指避免被拖累或通过外部进程（如构建命令、插件调用）间接分摊负载。
Sublime Text 本身不利用多核 CPU 进行编辑或渲染，所有核心逻辑（语法高亮、索引、插件通信）都运行在单线程主线程中；所谓“发挥多核”，实际是避免它被其他进程拖垮，或让插件/构建任务合理分摊到不同核心。
为什么 Sublime Text 不会跑满多个 CPU 核心
Sublime Text 是单线程 GUI 应用，底层用 C++ 编写，UI 渲染、事件循环、文件解析全在主线程完成。它不会像 VS Code 那样把语言服务、搜索、LSP 服务器等拆到独立进程——除非你主动调用外部工具。
常见误解：看到 subl 进程占了 100% CPU，就以为“没用好多核”。其实这只是单核跑满，其他核空闲，说明问题出在某个阻塞操作上，比如：
-
LSP服务器崩溃后反复重启（查看View → Show Console中是否刷屏出现starting...） - 未终止的
Build任务（如 Python 脚本里写了while True:） - 插件监听了整个
node_modules目录，每次文件变更都触发一次stat()系统调用
如何让构建任务真正用上多核
Sublime Text 的 Build System 本质就是调用 shell 命令，能否并行取决于你写的命令本身，而不是 Sublime。
例如，默认的 Python 构建只是执行 python -u "$file"，它只用一个核。但你可以改写为：
{
"cmd": ["make", "-j4"],
"working_dir": "${project_path:${folder}}",
"selector": "source.makefile"
}
关键点：
-
-j4明确告诉make使用 4 个并发作业，系统自动调度到空闲核心 - 确保你的构建脚本本身支持并行（如
webpack --max-old-space-size=4096 --thread-loader） - 避免在构建命令里写
sleep、read等阻塞操作，否则会卡住整个构建线程
插件能否帮 Sublime 利用多核
能，但得看插件怎么写。原生 Sublime API 不提供多线程接口，插件必须显式调用外部进程才能绕过主线程限制。
典型例子：
-
Terminus：每个终端实例都是独立子进程，天然多核友好 -
LSP类插件（如lsp-python）：pylsp本身是多线程 Python 服务，Sublime 只负责转发 JSON-RPC 请求 -
GitGutter：默认每 2 秒执行一次git diff，若项目大，建议设"git_gutter_async_timeout": 5并关闭"live_mode": false
注意：SublimeLinter 若配置成同步执行（"lint_mode": "load_save"），会在保存瞬间卡 UI；换成 "background" 模式，它会用 subprocess.Popen 启动独立进程，释放主线程。
哪些设置会让 CPU 更“均衡”地工作
没有设置能让 Sublime 自己多线程，但以下调整可防止它把某一个核长期霸占：
- 禁用实时索引：
"index_files": false（否则Indexer线程会持续扫描磁盘） - 增大文件变更检测间隔：
"filesystem_polling_interval": 5000（默认 1000ms，减少inotify或FindFirstChangeNotification调用频率） - 关闭动画：
"scroll_animation_fraction": 0和"hardware_acceleration": "none"（避免 GPU 驱动层频繁唤醒 CPU） - 对大项目，用
.sublime-project显式排除目录："folder_exclude_patterns": ["node_modules", "dist", ".git"]
最常被忽略的一点：虚拟机用户务必确认 subl 进程没被宿主机杀毒软件反复扫描缓存目录（Data/Cache/），这种 I/O 干扰会导致 CPU 使用率曲线剧烈抖动，看似多核忙，实则是磁盘瓶颈引发的调度失衡。
