最直接验证方式是ctrl+`打开控制台执行import os; print(os.environ.get('path', ''))，对比终端echo $path或echo %path%，若sublime中缺失python/rscript等路径，说明gui启动未继承shell配置；macos/linux需用open -a或subl从终端启动，windows须重启subl.exe，且build system应优先使用绝对路径而非依赖path。
在 Sublime 控制台里直接查 os.environ['PATH']
这是最直接、不依赖外部终端的验证方式，能看清 Sublime 当前进程实际拿到的 PATH 是什么。
按 Ctrl+`（反引号）打开 Sublime 控制台，输入：
import os; print(os.environ.get('PATH', ''))
对比你在终端里执行 echo $PATH（macOS/Linux）或 echo %PATH%（Windows）的输出。如果 Sublime 的 PATH 缺少 Python、Rscript、javac 等路径，说明 GUI 启动没继承 shell 配置——这不是配置错了，是启动方式导致的断层。
- macOS/Linux：图形界面双击启动 Sublime，默认不读
~/.zshrc或~/.bash_profile - Windows：即使改了系统环境变量，旧的
subl.exe进程仍用老 PATH，必须彻底退出再重开 - 输出为空或只有极短路径（如
C:\Windows\system32），基本可判定环境变量完全未透传
用 which / where 在终端里确认命令是否存在
Sublime 本身不装解释器或编译器，它只调用系统已有的命令。所以“验证环境变量”本质是验证这些命令能否被 Sublime 调到——而第一步，是确认它们在终端里真能跑。
别跳过这步。90% 的 command not found 错误，根源都在这里。
- macOS/Linux：在终端运行
which python3、which Rscript、which javac，必须有明确输出路径 - Windows：用 CMD 运行
where python、where Rscript.exe、where javac；注意路径中版本号要和你实际安装一致（如R-4.3.2） - 如果
which没输出，说明命令根本不在 PATH 里，Sublime 不可能调用成功——先解决系统级路径问题，再回头配 Sublime
从终端启动 Sublime 再测试构建系统
绕过 GUI 启动的环境隔离，是最可靠的验证路径。只要终端里能跑的命令，从终端启动的 Sublime 就一定能调用。
操作很简单：
- macOS：终端执行
open -a "Sublime Text"或已配好subl时直接subl . - Linux：执行
subl（需已配置 PATH 和 desktop 文件） - Windows：CMD 中进入 Sublime 安装目录，运行
subl.exe，或直接用完整路径如"C:\Program Files\Sublime Text\subl.exe" - 启动后，打开一个对应文件（如
.py、.java），按Ctrl+B测试构建是否成功
如果终端启动能跑通，但 Dock/开始菜单启动不行，就坐实了是 GUI 环境变量加载机制的问题，不是配置内容有误。
检查 Build System 里是否硬编码了错误路径
很多人以为配了系统 PATH 就万事大吉，结果 shell_cmd 里写的是 python，而系统只有 python3；或者写了 javac，但实际路径是 /usr/lib/jvm/jdk-17.0.1/bin/javac —— PATH 失效时，这种写法必然失败。
真正稳的写法是显式指定绝对路径：
- Python 构建：
"shell_cmd": "/opt/homebrew/bin/python3 -u \"$file\"" - Java 编译：
"shell_cmd": "/usr/lib/jvm/jdk-17.0.1/bin/javac -encoding UTF-8 \"$file\"" - R 运行：
"shell_cmd": "/opt/homebrew/bin/Rscript -e \"source('$file')\"" - 路径必须和
which输出完全一致，包括版本号子目录
硬编码路径看似笨重，但它把“PATH 是否生效”这个不确定因素直接移除，让验证过程变得可预期。很多配置反复失败，就是卡在对 PATH 的过度信任上。
