Ctrl+B卡死时应执行sublime.active_window().run_command("exec", {"kill": True})强制终止构建进程，并关闭index_files、排除node_modules等目录、禁用word_wrap等五项配置以根治卡顿。
Sublime Text 一键运行（Ctrl+B）卡死，不是构建脚本慢，而是 Sublime 在后台持续加载语法高亮、索引文件、触发插件扫描——尤其当构建目标是 Java 编译或运行时，javac 进程未退出、SublimeLinter 同步阻塞、或 GitGutter 在大项目中反复调用 git status，都会让 UI 线程挂起数秒甚至永久无响应。
Ctrl+B 卡住时怎么立刻杀掉构建进程？
Sublime 没有内置的“终止构建”按钮，但可通过以下方式强制中断：
- 按
Ctrl+`打开控制台，输入sublime.active_window().run_command("exec", {"kill": True})回车——这是 Sublime 原生支持的硬终止命令，会 kill 当前正在运行的exec子进程（包括卡住的javac或java） - Windows 下若控制台也无响应，直接在任务管理器中结束所有
javaw.exe或java.exe进程（注意别误杀 IDE） - macOS/Linux 终端执行
pkill -f "javac\|java.*Main"，精准匹配未退出的编译/运行进程 - 不推荐关整个 Sublime：它会丢失未保存内容，且重启后可能再次触发相同卡死链
为什么 Java 构建一卡就是 10 秒以上？
根本原因不是 javac 本身慢，而是 Sublime 在构建前后多做了三件事：
-
index_files: true（默认）导致 Ctrl+B 前先扫描整个项目目录，尤其含node_modules或.git时，IO 阻塞构建线程 -
SublimeLinter默认设为"lint_mode": "background"，每次构建都并发启动新eslint或javac进程，不等上一个结束就开下一个，进程堆积 - 构建输出面板启用
word_wrap: true+ 含超长 classpath 的错误信息，Sublime 会逐字符计算软换行位置，百万字符日志里卡死常见 - Java 构建脚本中用了
-verbose或-Xdiags:verbose，输出大量调试行，Sublime 尝试对每行做语法高亮，内存暴涨
用户设置里必须改的五项关键配置
这些不是可选项，是避免 Ctrl+B 卡死的底线配置，全部加到 Preferences → Settings – User 中：
-
"index_files": false：关全局索引，Ctrl+B 不再等待文件扫描完成 -
"folder_exclude_patterns": ["node_modules", ".git", "target", "build"]：排除构建产物目录，防止插件误扫 -
"word_wrap": false：构建输出禁用自动换行，避免渲染阻塞 -
"draw_white_space": "none"：跳过空格/制表符渲染，减少字符串处理开销 -
"large_file_size_limit": 10：单位 MB，设小一点，让日志、class 文件等自动降级为 Plain Text，不触发任何解析器
Java 构建文件里最容易被忽略的两个参数
光写死 javac 路径不够，没加这两项，Ctrl+B 仍可能卡在编码或路径问题上：
-
"encoding": "utf-8"：显式指定源码编码，否则 Windows 上默认 GBK 读取 UTF-8 Java 文件会报错并卡住（错误如illegal character: \ufffd） -
"shell_cmd": "javac -encoding utf-8 -d . ${file}"：必须加-d .，否则javac生成的 class 文件散落在各源码目录，后续java ${file_base_name}找不到类，反复重试导致假死 - 别信
"path"或"env"字段：它们只影响子进程环境变量，但 Sublime 构建系统本身不继承，javac调用失败时不会提示 PATH 错误，只会静默卡住
真正卡死的根源往往不在构建命令本身，而在 Sublime 对“构建完成”的定义——它要等语法高亮重绘、行号更新、插件回调全部返回才算结束。所以最稳的做法，是让构建过程尽可能“轻”：关索引、关高亮、关插件、关换行，剩下的才是 javac 自己的事。
