sublime ctrl+b 运行慢的根源是构建系统无法定位 node 等解释器或受插件干扰；需用绝对路径配置构建系统、避免后台常驻逻辑、禁用劫持构建的插件（如 sublimelinter），并区分普通运行与 --inspect-brk 调试模式。
Sublime 运行代码（Ctrl+B）慢，基本不是 Sublime 本身的问题，而是构建系统调用 node 或其他解释器时被卡在了外部环节——比如找不到命令、路径错误、插件拦截、或构建后等待无响应。真正影响“运行反馈速度”的，是配置的健壮性，不是编辑器渲染。
为什么 Ctrl+B 按下后没输出、卡住或报 'node' is not recognized
根本原因：Sublime 的构建系统无法定位到 node 可执行文件。它不读取你的 shell 环境变量（如 zsh 的 $PATH），尤其在 macOS GUI 启动、Windows 从快捷方式启动时更明显。
- 先在终端里运行
which node（macOS/Linux）或where node（Windows），拿到绝对路径，比如/usr/local/bin/node或C:\Program Files\nodejs\node.exe - 新建构建系统时，别写
"cmd": ["node", "$file"]，直接写绝对路径："cmd": ["/usr/local/bin/node", "$file"] - 确保
selector是"source.js"，否则 .js 文件不会自动匹配该构建系统 - 保存为
Packages/User/Node.sublime-build（可通过Preferences → Browse Packages…进入User目录）
debugger; 在 Ctrl+B 下完全没反应？这是对的
因为普通 node $file 不启用 V8 Inspector 协议，debugger; 语句会被静默忽略——这不是 bug，是 Node.js 的默认行为。
- 想让断点生效，必须显式加
--inspect-brk："cmd": ["/usr/local/bin/node", "--inspect-brk", "$file"] - 但 Sublime 构建系统不会自动打开 Chrome DevTools；你得手动访问
chrome://inspect，等目标出现后点击inspect - 日常开发别把
--inspect-brk设为默认构建，建议另存为Node Debug.sublime-build，避免每次运行都卡住
哪些插件会偷偷劫持 Ctrl+B 或拖慢构建输出？
某些插件会在构建前/后注入钩子，导致延迟几秒才看到输出，甚至阻塞主线程。最典型的是监听保存事件、自动格式化、或调用外部 LSP 服务的插件。
- 重点排查：
SublimeLinter（若未配好，会反复 spawneslint进程）、JsFormat、ESLint-Formatter、任何带on_post_save的自定义插件 - 临时验证：用安全模式启动（按住
Ctrl/Cmd双击图标），如果此时Ctrl+B秒出结果，问题一定出在插件 - 禁用方式：
Ctrl+Shift+P→Package Control: Disable Package，选中后重启生效；比卸载更安全，保留配置
构建输出面板卡在 “Building…” 不动？检查这三项
这不是构建慢，是 Sublime 等不到进程退出或 stdout 结束，常见于后台长期运行、未正确关闭的子进程。
- 确认你的 JS 脚本末尾有明确退出：比如加
process.exit(0)，或避免setInterval/http.createServer().listen()这类常驻逻辑 - 构建系统里加
"shell": true（尤其 Windows 上），能绕过某些 cmd 解析异常 - 如果用了
console.clear()或 ANSI 颜色码，部分旧版 Sublime 输出面板解析会卡住；可临时注释掉测试
真正容易被忽略的是：Sublime 的构建系统本身不缓存、不复用进程，每次 Ctrl+B 都是全新 fork()。所以“快”不靠编辑器优化，而靠减少外部依赖、缩短脚本生命周期、以及切断插件干扰链。一个干净的 .sublime-build + 绝对路径 + 无后台逻辑的脚本，才能做到按下即见结果。
