Sublime Text 4 并不会原生编译 Rust，所谓配置环境，实际上是把几件事接起来：让 cargo 或 rustc 能在 Sublime 进程里被调用、让 .rs 文件被识别成 Rust、让构建命令在正确目录执行、再把报错信息映射回源码位置。只要其中一环没接上，Ctrl+B 不是没有反应，就是直接报 No build system。下面按排查顺序展开，读完你可以判断问题到底出在 PATH、语法识别、构建系统，还是 LSP 连接。
先确认 Sublime 里真的能调用 cargo 和 rustc
很多人会先去装语法插件或复制构建脚本，但最先要查的其实是环境变量。终端里能运行 Rust 命令，不代表 Sublime 内部也能运行，因为它启动时读取的是自己的环境，而不是你当前 shell 会话里的配置。
先按 Ctrl+` 打开 Sublime 控制台，输入下面这行：
import os; print(os.environ.get('PATH'))检查输出里是否包含 .cargo/bin，例如 macOS/Linux 常见的 /Users/xxx/.cargo/bin，或 Windows 下的 C:Usersxxx.cargobin。如果这一段路径不存在，后面的构建和 LSP 都会跟着失效。
Windows 怎么处理
- 把
%USERPROFILE%.cargobin加入系统环境变量。 - 修改后要彻底退出 Sublime Text，再重新打开，只关窗口通常不够。
- 如果仍然无效，先在终端分别执行
cargo --version和rustc --version，确认 Rust 工具链本身可用。
macOS 和 Linux 为什么更容易踩坑
- 通过 GUI 启动的 Sublime，通常不会加载
~/.zshrc、~/.bashrc之类的 shell 配置。 - 更稳妥的做法是从终端使用
subl命令启动 Sublime。 - 如果你已经把
~/.cargo/bin写进了~/.zshrc，记得执行source ~/.zshrc，然后完全退出并重开 Sublime。 - 验证还是失败时，不要先怀疑插件，优先重装 rustup，再检查
cargo --version与rustc --version。
右下角语法必须是 Rust，不能停在 Plain Text
Sublime 的很多能力都依赖语法选择器匹配，Rust 也不例外。语法高亮、构建系统触发、LSP 补全和诊断，基本都围绕 source.rust 这个 selector 工作。如果右下角显示的是 Plain Text，那么你后面配置得再完整，也可能完全不生效。
打开任意一个 .rs 文件，点击右下角状态栏中的语法名称。如果当前是 Plain Text，手动切换到 Rust。这一步不要省略，Sublime 不会可靠地替你“猜”出这是 Rust 文件。
列表里没有 Rust 时该怎么办
- 通过 Package Control 安装
RustEnhanced。 - 这里要注意，不是安装
Rustby rust-lang；两者共存可能发生冲突，结果就是状态栏一直停在Plain Text。 - 安装完成后，进入
View → Syntax → Rust → Rust，把它设成默认语法，后续打开.rs文件时更省事。
这一节看起来只是“显示名称”问题，但它其实是整个链路的入口。语法不对，selector 不匹配，构建系统和 LSP 都不会按 Rust 场景工作。
构建系统怎么写，Ctrl+B 才能真正跑通
Rust 在 Sublime 里能不能顺利编译，关键不是有无 JSON 文件，而是其中几个字段是否配对正确。网上很多现成配置能弹出构建面板，却因为缺少工作目录或错误匹配规则，最后还是不能正常运行、也不能双击定位错误。
优先建议使用 cargo，而不是直接调用 rustc。只要你在做的是标准 Rust 项目，cargo run 通常是更合理的入口。
为什么优先用 cargo run
- 构建命令建议写成
"shell_cmd": "cargo run"，不要直接用"cmd"。 shell_cmd会通过系统 shell 执行，更容易复用 PATH 和别名配置。- 如果改成
cmd直接拉起进程，Windows 下尤其容易因为路径带空格而出问题。
working_dir 是最容易漏掉的字段
下面这一项通常必须写：
"working_dir": "${project_path:${folder}}"原因很直接：如果没有它，cargo 往往会在当前文件所在目录执行，而不是在项目根目录执行。只要执行目录不对，Sublime 很容易报出 no Cargo.toml found，看起来像是 Rust 没装好，实际上只是没有进入正确目录。
单文件测试可以直接走 rustc
如果你只是临时验证一个独立文件，也可以改用：
"shell_cmd": "rustc $file -o $file_path/$file_base_name"但这只适合包含 fn main() { } 的单文件程序，不适合依赖 Cargo 项目结构、外部 crate 或完整工程配置的场景。
改完后还要手动启用
- 写好构建系统之后，到
Tools → Build System → Rust手动勾选你刚配置的那个。 - Sublime 不会自动帮你切换到新建的构建系统，所以不少人明明 JSON 没写错，按
Ctrl+B仍然没有命中 Rust 配置。 - 如果还希望双击报错能跳回源码，记得同时检查
file_regex是否与 Rust 编译输出匹配，否则只会看到错误文本，无法定位文件和行号。
配置 rust-analyzer 时，重点是二进制位置和绝对路径
语法高亮和编译跑通后，很多人会继续接入 LSP。但 Rust 这一部分最常见的问题，不是插件没装，而是 rust-analyzer 可执行文件本身没被正确发现。
cargo install rust-analyzer 这条路已经不适合作为当前方案；而 rustup component add rust-analyzer 在 macOS 和部分 Linux 环境下，也可能出现静默失败。结果就是 LSP 插件压根没连上，却不给出明显提示。
更稳的做法是下载官方二进制
- 到 rust-lang/rust-analyzer/releases 下载对应平台的可执行文件，例如
rust-analyzer-x86_64-unknown-linux-gnu。 - 解压后会得到单个无后缀二进制文件。
- Linux/macOS 可以放到
/usr/local/bin/rust-analyzer。 - Windows 可以放到
%USERPROFILE%.cargobinrust-analyzer.exe。
LSP 设置为什么要写绝对路径
- 先在终端执行
rust-analyzer --version，确认文件本身可运行。 - 接着在 Sublime 的 LSP 配置里，把
"command"写成绝对路径。 - 不要只写
["rust-analyzer"]，因为这仍然依赖 Sublime 当下拿到的 PATH，而这恰恰是前面最容易出问题的地方。
语法范围不一致时会静默失效
即使二进制没问题，LSP 仍然可能不工作。常见原因是设置里的语法范围和当前文件实际语法不一致，例如：
"scopes": ["source.rust"]"syntaxes": ["Packages/Rust/Rust.sublime-syntax"]
这两项必须和右下角当前选中的 Rust 语法严格对应。只要对应不上，LSP 就可能直接放弃连接，而且界面上不会给出足够明显的错误提示。
最后再检查两处最容易忽略的断点
把整套配置串起来看，真正最容易被忽视的，其实只有两件事。
- 第一，Sublime 启动后会把环境变量固化在当前进程里。也就是说，无论你是刚改了 PATH，还是刚安装了 rustup，只要没有彻底退出再启动，编辑器里看到的仍然可能是旧环境。
- 第二，右下角的语法标识如果没有手动切到
Rust，整个构建链就会在起点断掉。此时你看到的往往不是明确报错，而是构建系统、LSP、语法高亮一起表现异常。
因此，排查顺序建议固定下来：先看 PATH，再看右下角语法，再看构建系统里的 shell_cmd 和 working_dir，最后才去检查 rust-analyzer 和 LSP 映射。按这个顺序处理，通常比盲目重装插件更快。
