必须用“file → open folder”打开含cargo.toml的根目录，确保${project_path}正确；.sublime-project文件需置于仓库根目录，配置working_dir、rust检查与格式化等选项，才能统一团队rust开发行为。
怎么让 Sublime Text 正确识别 Rust 项目根目录
Sublime Text 不会自动推断 Cargo 项目在哪，它只认 .sublime-project 文件或你手动打开的文件夹路径。如果你双击一个 main.rs 单独打开，${project_path} 就是 src/ 目录，cargo run 必然报 error: no Cargo.toml file found。
必须用 File → Open Folder 加载整个含 Cargo.toml 的目录，右键标签页 → Reveal in Side Bar 确认左侧边栏顶部显示的是项目根（即能看到 Cargo.toml 和 src/ 同级）。
-
"working_dir": "${project_path:${folder}}"这行必须写在 Build System 里，不能省；${file_path}或${file}都会导致 cargo 在错误目录执行 - 如果项目嵌套多层（比如
workspace1/crates/mylib），直接打开workspace1更稳妥，再靠.sublime-project控制子模块行为 - 不建
.sublime-project也能跑，但所有配置（如 lint 工具、格式化开关）只能靠全局设置，团队协作时极易不一致
如何写一个可提交到 Git 的 .sublime-project 文件
项目级配置才是团队统一 Rust 行为的关键。把 .sublime-project 放进仓库根目录，和 Cargo.toml 并列，新成员 clone 后开箱即用。
典型内容如下（注意 JSON 格式，字段名和引号不能错）：
{
"folders": [
{
"path": "."
}
],
"settings": {
"rust_syntax_checking_method": "clippy",
"rust_on_save": "check",
"rust_show_errors_inline": true,
"rust_format_on_save": true
}
}
-
"rust_syntax_checking_method": "clippy"强制用 Clippy 替代 rustc 默认检查，避免团队漏掉常见反模式 -
"rust_on_save": "check"表示保存时只做检查，不编译——防止误触cargo build拖慢编辑体验 - 别把
rust_lint_on_save和rust_on_save混用，后者是 Rust Enhanced 的主控开关，前者已废弃 - 如果项目用工作区（
[workspace]），确保"path": "."指向 workspace 根，不是某个 crate 子目录
为什么 RustEnhanced 的全局设置不如 .sublime-project 灵活
Packages/User/RustEnhanced.sublime-settings 是全局兜底，但它无法区分不同项目需求。比如 A 项目要求 rustfmt + clippy，B 项目还在用旧版 Rust 编译器，禁用 clippy 更稳——全局设置做不到这点。
- 全局设置里的
"cargo_build": {"toolchain": "stable"}会被.sublime-project中同名字段完全覆盖，不是合并 - 插件加载顺序影响实际生效项：Sublime 先读全局，再读项目，项目设置优先级更高
- 如果团队用
rust-analyzer，其 LSP 配置也建议写进.sublime-project的"settings"下，避免和全局LSP.sublime-settings冲突 - 别在全局设置里硬编码
racer路径，不同开发者 Rust 安装路径可能不同；项目配置里也不推荐，应依赖 PATH 或shell: true
容易被忽略的路径陷阱：Windows 和 macOS 的 working_dir 差异
"working_dir": "${project_path:${folder}}" 在 Windows 和 macOS 上行为一致，但前提是 Sublime 进程本身能正确解析环境变量。很多失败其实卡在更底层。
- macOS 用户从 Dock 启动 Sublime，
${project_path}可能为空——因为 GUI 进程没加载 shell 配置；改用终端执行subl .打开项目，${project_path}才可靠 - Windows 用户若把项目放在 OneDrive 或 WSL 路径下，
${project_path}可能返回 UNC 路径（如\wsl$Ubuntuhomeusermyproj），部分 cargo 插件会拒绝识别；建议用本地盘符路径（C:devmyproj） - 如果项目路径含空格或中文，
shell_cmd必须设"shell": true，否则cargo run在 Windows 上大概率因路径截断失败 - 验证方式：建一个最简 Build System，
"shell_cmd": "pwd && ls Cargo.toml"，看输出是否真在项目根目录
