sublime text 的 build system 文件必须置于 packages/user/ 目录下，后缀为 .sublime-build；跨平台推荐使用 cmd 数组语法，变量仅在 cmd 或 shell_cmd 中生效；万能运行需设 selector 为 "source | text" 并用 shell 脚本判断后缀；调试时注意 stderr 重定向与环境路径一致性。
Build System 文件必须放在 Packages/User/ 目录下
Sublime Text 的 Build System 不会从任意路径加载，只认 Packages/User/ 这个固定位置。如果你把 .sublime-build 文件丢在桌面或项目根目录，它根本不会出现在 Tools → Build System 菜单里。
- Windows：打开
Preferences → Browse Packages…，进User/文件夹 - macOS：菜单栏
Sublime Text → Preferences → Browse Packages…，同样进User/ - Linux：通常在
~/.config/sublime-text-3/Packages/User/ - 文件名随意，但后缀必须是
.sublime-build，比如RunPython.sublime-build
用 shell_cmd 还是 cmd？看系统和命令类型
Windows 上直接写 python $file 会失败——因为 cmd 不认识 $file 这种变量；而 macOS/Linux 的 shell（bash/zsh）能解析。所以跨平台兼容的写法得靠 cmd + 数组形式，让 Sublime 自己拼接：
{
"cmd": ["python", "$file"],
"selector": "source.python",
"file_regex": "^.*?([^:]*):([0-9]+):?([0-9]+)?:? (.*)$"
}
-
shell_cmd适合简单命令、带管道或重定向的场景（如shell_cmd: "python $file 2>&1"），但 Windows 下需确保用的是 PowerShell 或已启用shell: true -
cmd更可控，尤其对空格路径、多参数命令更安全，推荐优先用 -
$file、$file_path、$file_base_name这些变量只有在cmd数组或shell_cmd字符串里才生效，不能用在其他字段中
如何让一个 Build System “万能运行”当前文件（不管后缀）？
关键不是删掉 selector，而是把它设成宽泛匹配，再配合脚本判断实际类型。最简方案是去掉 selector，但副作用是它会出现在所有文件的构建菜单里，容易误点。更稳妥的做法是用 selector 匹配通用范围：
{
"cmd": ["sh", "-c", "case $1 in *.py) python $1 ;; *.js) node $1 ;; *.rb) ruby $1 ;; *) echo 'Unsupported extension'; exit 1 ;; esac", "_", "$file"],
"selector": "source | text",
"variants": [
{
"name": "Run with args",
"cmd": ["sh", "-c", "read -p 'Args: ' args; $1 $2 $args", "_", "python", "$file"]
}
]
}
-
selector: "source | text"表示所有源码类或纯文本文件都可触发该构建系统 - 真正“万能”的逻辑要靠 shell 脚本或外部包装器判断后缀，避免硬编码一堆
if在 JSON 里 - 别信网上抄来的
"selector": ""，Sublime 会忽略空字符串，等于没设 - 如果想支持中文路径，Windows 下务必用
cmd+chcp 65001前置，否则python读文件可能报 UnicodeDecodeError
调试 Build System 失败时，先看 Tools → Build Results
构建失败不报错？或者报错但看不懂？不是 Sublime 坏了，大概率是输出被吞了或编码乱了。默认情况下，错误信息走 stderr，但 Sublime 只捕获 stdout，除非你显式重定向：
- 加
"quiet": false确保输出不被压制 - Windows 下 cmd 默认不输出 stderr 到控制台，改用
"cmd": ["cmd", "/c", "python $file 2>&1"] - macOS/Linux 如果用
shell_cmd，记得末尾加2>&1，不然 Python 的 traceback 就消失了 - 最有效的调试方式：临时把
cmd改成["echo", "$file"]，确认变量是否被正确展开
真正的坑不在语法，而在路径、编码、权限这三块。比如 macOS 上用 #!/usr/bin/env python3 写的脚本，Build System 却调用了系统自带的 python（即 Python 2.7），结果语法错误——这种问题得靠 which python 和 echo $PATH 对齐环境。
