不少开发者遇到过这样一个让人抓狂的场景：在终端里 node -v 跑得好好的，一回到 Sublime Text 按 Ctrl+B，就甩给你一句“node is not recognized”或“command not found”。
这跟 Sublime 没啥关系，也别急着重装 Node。问题核心在于：Sublime Text 本身不运行 Node.js，它只是调用你系统里已安装的 node 命令。所有配置失败的根本原因，十有八九是终端能跑 node -v，但 Sublime 启动时根本没拿到正确的 PATH——尤其是 macOS 或 Linux 的图形界面下（比如从 Spotlight 或 Dock 启动），~/.zshrc 根本没被加载，环境变量自然就断了。
为什么 Ctrl+B 报 “node is not recognized” 或 “command not found”
首先要弄明白，为什么会报这个错。这可不是 Sublime 的 bug，而是环境变量继承断裂的典型表现。
- Windows 这边，常见的原因有两个：一是安装 Node.js 时忘了勾选“Add to PATH”；二是用了 Microsoft Store 版本，这个版本默认不写系统变量。
- macOS/Linux 上，问题则出在图形会话不读 shell 配置文件。你在终端里执行
which node有输出，但在 Sublime 里就是查不到，说白了，就是启动环境不一样。
怎么解决？思路其实很简单。
- 第一步，在终端执行
which node（macOS/Linux）或where node（Windows），拿到绝对路径。比如/opt/homebrew/bin/node或C:\Program Files\nodejs\node.exe。 - 第二步，拿到这个路径之后，别太依赖
"shell": true这个选项——macOS 上它可能加载错 shell 配置，Windows 上反而更容易卡住。 - 第三步，也是最关键的一步：直接把上面拿到的完整路径，硬编码到构建系统的
"cmd"字段里。这样一来，就彻底绕过了 PATH 的依赖，再也不用担心环境变量的问题了。
这个方法看着“土”，但恰恰是最少意外的方案。
如何写一个真正生效的 .sublime-build 文件
接下来，还是得老老实实写一份可靠的 .sublime-build 文件。有几个细节需要特别注意。
文件名必须以 .sublime-build 结尾，而且必须保存到 Packages/User/ 目录下。macOS 上的路径是 ~/Library/Application Support/Sublime Text/Packages/User/，Windows 则是 %APPDATA%\Sublime Text\Packages\User\。内容必须是合法的 JSON，不能有注释、尾随逗号或单引号，一个标点符号错了都不行。
"cmd"字段务必是数组，比如["/opt/homebrew/bin/node", "$file"]，千万别写成字符串"node $file"。"working_dir": "$file_path"这一项绝对不能省。否则，脚本里的require('./utils')会因为工作目录错误，直接报Cannot find module。"selector": "source.js"可以让这个构建系统只对.js文件生效，也算是用起来更顺手。- Windows 用户如果用了 nvm-windows，有个额外的小坑：得先在命令行里执行
nvm use 18.18.2，再启动 Sublime，否则node可不在 PATH 里。
运行带参数或需要交互的脚本为什么卡住
还有一些场景，是配置了绝对路径也搞不定的。
Sublime 的构建输出面板本身不支持 process.stdin。一旦脚本里有 readline、prompt() 或任何等待用户输入的逻辑，它就会卡住，或者直接退出。这是机制的硬性限制，不是配置能解决的。
- 如果只是传固定参数，可以硬编码：
"cmd": ["node", "$file", "--port", "3000"]，这样最简单。 - 如果需要临时传参，就别在 Sublime 里折腾了，直接切到终端，老老实实敲
node index.js --debug。 - 中文输出乱码的话，可以在构建文件里加一句
"encoding": "utf-8"，但更稳妥的办法是确保终端和系统 locale 保持一致。
说到底，硬编码 node 的绝对路径，虽然看起来有点“笨”，但它是绕开所有环境变量陷阱的最直接方案。很多人反复折腾 "shell": true 和环境变量，最后才发现，恰恰是 which node 输出的那个路径，才是 Sublime 真正认的“node”。
