which subl或where subl可直接验证subl命令是否被终端识别，有输出即存在，无输出说明未注册；subl --version成功返回版本号才是最可靠的可用性验证。
which subl 或 where subl 能直接告诉你命令是否存在
终端里敲 which subl（macOS/Linux）或 where subl（Windows），有输出路径就说明系统能定位到它；没输出就是根本没注册进 shell 环境。这个命令不依赖 PATH 配置是否“看起来正确”，只反映当前 shell 实际加载的结果。
常见误判点：
- 在 GUI 启动的终端里运行成功，不代表 Sublime 本身能继承该 PATH（Sublime 不读 .zshrc/.bash_profile）
- PowerShell 里
where subl找不到，但 CMD 里可以 → 说明 PATH 只写进了用户环境变量，没写进系统级，或者 PowerShell 没 reload 配置 -
which subl返回 /usr/local/bin/subl，但subl --help报错 Permission denied → 实际是软链接目标失效，比如 Sublime 升级后重装路径变了，/usr/local/bin/subl 还指向旧的 .app 内部路径
subl --version 是最轻量的可用性验证
只要 subl --version 能打印出类似 Sublime Text Build 4162 的输出，就证明二进制可执行、权限正常、GUI 上下文初始化也基本 OK。比 subl . 更可靠，因为后者可能卡在沙盒弹窗、权限拒绝或空目录处理逻辑里。
注意：
- macOS Sonoma+ 或启用了 Full Disk Access 限制时，
subl --version成功但subl .无响应 → 不是命令问题，是系统拦截了 GUI 应用从终端继承工作目录的能力 - Windows 上如果
subl --version报错“不是内部或外部命令”，90% 是subl.exe根本不存在，别折腾 PATH，先去安装目录翻一遍 - Linux Snap/Flatpak 安装的版本，
subl --version必然失败 —— 这类包默认不暴露subl命令，得换 .deb 或手动解压版
subl . 打不开当前目录？别急着改 PATH
subl . 没反应、卡住、弹空白标签页，大概率和 PATH 无关，而是操作系统级限制或路径解析问题。
快速排查项：
- 路径含空格或中文：必须用引号包裹，例如
subl './my project/file.js'，否则 shell 截断参数 - 当前目录权限不足（尤其 macOS Sonoma+ 的隐私控制）：终端运行
ls -la看是否可读，不行就先chmod +x . - Sublime 正在后台运行且启用了“退出时关闭所有窗口”：此时
subl .会尝试复用已有进程，但若主窗口已关、后台进程残留，就表现为静默失败 - Windows 下用了反斜杠路径如
subl ..\file.py：PowerShell 会把\f当转义符，应改用正斜杠../file.py或双反斜杠..\file.py
Mac 上 /usr/local/bin/subl 软链接容易失效
Apple Silicon Mac（M1/M2）用户特别注意：/usr/local/bin 默认不在 PATH 中，尤其当你用 Homebrew 安装其他工具时，PATH 可能优先走 /opt/homebrew/bin。这时候即使 sudo ln -s ... /usr/local/bin/subl 成功，which subl 仍为空。
更稳的做法：
- 确认你的 shell 初始化文件（
~/.zshrc）里有export PATH="/opt/homebrew/bin:$PATH"（Homebrew 用户）或export PATH="/usr/local/bin:$PATH"（Intel Mac） - 软链接目标路径要严格匹配实际安装位置：
/Applications/Sublime Text.app和/Applications/Sublime Text 4.app是两个不同路径，升级后旧链接立刻失效 - 用菜单栏 Sublime Text → Install Command Line Tool 替代手动建链接：它会自动处理空格、路径变更和权限，比
ln -s更健壮
subl 启动的实例，才携带完整的 shell PATH。这点不厘清，后面所有构建系统、插件调用、shell 命令都可能莫名其妙失败。
