subl --version 是否有效取决于软链接是否指向真实可执行文件；若 which subl 无输出，说明未注册path；若链接目标非可执行文件或存在多版本冲突，则--version会失败或返回旧版build号。
subl --version 命令是否有效，取决于软链接是否指向真实可执行文件
终端输入 subl --version 报 command not found，不是版本问题，而是 subl 命令根本没注册进系统 PATH。Linux/macOS 下它只是个软链接，不是安装时自动写入的系统命令。
检查步骤：
- 运行
which subl—— 若无输出，说明软链接缺失或未生效 - 运行
ls -l $(which subl)—— 确认目标路径是否指向/opt/sublime_text/sublime_text（Ubuntu/Debian）或/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl（macOS） - 若链接指向目录而非可执行文件（比如指向
/opt/sublime_text/），--version必然失败
确认 subl 指向正确后，subl --version 输出什么才算 ST4
subl --version 的输出格式固定为一行：Sublime Text Build XXXX。关键看数字部分——Build 4xxx 是 ST4，Build 3xxx 是已停止维护的 ST3。
常见误判点：
- 输出
Sublime Text Build 4200→ 正确 ST4 - 输出
Sublime Text Build 3211→ ST3（最终版，无更新支持） - 输出含
arm64或universal→ 大概率是 ST4 原生 macOS ARM 版；若标“translated”，实际是 ST3 通过 Rosetta 2 运行
dpkg -l sublime-text 查不到版本？你可能装的是 tarball 或官网 .deb 包外的版本
dpkg -l sublime-text 只对通过 apt install sublime-text 或官方 .deb 包安装的版本有效。如果你是从官网下载 .tar.bz2 手动解压、或用 Snap/Flatpak 安装，dpkg 就查不到任何记录。
此时唯一可靠方式只有两个：
- 在 Sublime Text 内：Help → About Sublime Text（Windows/Linux）或 Sublime Text → About（macOS），弹窗首行即为权威 Build 号
- 终端运行
subl --version（前提是软链接已正确配置）
别信 subl -v、subl -help 或进程名里的 “sublime_text_4”，那些都不算数。
subl 命令能用但 --version 不显示 Build 号？大概率是 PATH 混淆了多个版本
有些用户手动建过多个 subl 链接（比如同时存在 ST3 和 ST4 的 bin 目录），shell 会优先取 PATH 中靠前的那个。结果 subl 能启动，但 subl --version 返回的可能是旧版本信息。
排查方法：
- 运行
type -a subl，列出所有匹配的subl路径 - 逐个执行
/path/to/subl --version，确认哪个才是你日常打开编辑器用的那个 - 删掉冗余链接，只保留指向当前主版本可执行文件的那一个（如
/opt/sublime_text/sublime_text）
这个冲突在升级 ST4 后尤其容易被忽略——旧的 subl 链接没删，新版本装在别处，命令行和 GUI 实际跑的根本不是同一套二进制。
