sublime的rust错误跳转失效主因是file_regex在json中双重转义错误，正确写法为"^(.+):([0-9]+):([0-9]+):s(.)$"，需配合working_dir="${project_path:${folder}}"确保cargo在项目根执行。
Sublime 的 Rust 错误跳转失效，90% 是 file_regex 写错了——不是正则本身难，而是 JSON 字符串里反斜杠和空格要双重转义，漏一个就变纯日志。
为什么 cargo 错误双击不跳转到 src/main.rs:2:5
Sublime 构建系统靠 file_regex 从命令输出中提取文件路径、行号、列号。Rust 编译器错误典型格式是：src/main.rs:2:5: error[E0308]: mismatched types。匹配它必须用精确正则，且必须适配 JSON 字符串解析规则。
-
"file_regex": "^(.+):([0-9]+):([0-9]+):\s*(.*)$"是唯一可靠写法：开头^锚定，(.+)捕获文件名（含src/），两个([0-9]+)分别捕获行/列，\s*匹配冒号后任意空白（注意是双反斜杠） - 常见错误：写成
s*（漏了反斜杠）、s*（单反斜杠，在 JSON 里被当转义失败）、或漏掉^导致匹配到错误消息中间的数字 - Windows 路径如
C: oomain.rs:10:4会崩——Rust 在 Windows 上默认仍输出 Unix 风格路径，不用额外适配
如何验证 file_regex 是否真生效
光看构建输出不够，得确认 Sublime 是否成功解析出坐标。最直接方式是触发一次编译错误，然后按 Ctrl+Shift+P 输入 Build Results，选 Next Result 或 Previous Result —— 如果能跳转，说明正则对；如果只高亮整行日志，没跳转，就是正则没匹配上。
- 在构建系统 JSON 中临时加
"quiet": false，确保错误原样输出，方便肉眼比对 - 把
file_regex值粘贴进在线正则测试工具（如 regex101），选 PCRE2 引擎，输入src/main.rs:2:5: error[E0308]看分组是否捕获到src/main.rs、2、5 - 别信网上抄的
"^(.*?):(\d+):(\d+):—— 它漏掉\s*，遇到:（冒号+空格）就断匹配
构建系统里 shell_cmd 和 file_regex 必须配套
shell_cmd 输出格式决定 file_regex 怎么写。Rust 项目几乎都用 cargo，但不同子命令输出结构不同：
-
"shell_cmd": "cargo build"输出带完整路径和多级冒号，匹配上面那个正则即可 -
"shell_cmd": "cargo check"输出格式一致，同样适用 -
"shell_cmd": "rustc src/main.rs"输出是src/main.rs:2:5: error，也兼容，但不推荐——绕过 Cargo.toml 依赖管理，容易漏 crate - 绝对不要用
"cmd"字段替代"shell_cmd"：前者不走 shell，rustc找不到 PATH，且无法展开$PATH变量
file_regex 写对了还是跳转错位？检查 working_dir
正则匹配成功，但双击跳转到错误文件或报 Unable to open ...，问题不在正则，而在工作目录。Cargo 必须在项目根（含 Cargo.toml）下执行，否则 src/main.rs 路径是相对构建系统所在目录算的，不是项目根。
- 构建系统 JSON 中必须显式写
"working_dir": "${project_path:${folder}}"，不能省略 - 如果项目没打开文件夹（只开了单个 .rs 文件），
${folder}为空，${project_path}也为空，working_dir就变成空字符串，cargo 在当前文件目录跑，找不到Cargo.toml - 验证方法：在构建系统里加
"shell_cmd": "pwd && cargo build"，看输出路径是不是你 Cargo.toml 所在目录
真正卡住人的从来不是正则语法，而是 JSON 字符串转义、shell 工作路径、以及 cargo 输出格式三者咬合不上。调通前先确认 working_dir 对不对，再抓一条真实错误日志去测正则，最后看 Sublime 控制台有没有 Build system executed... 成功提示——这三步漏任何一环，跳转就静默失效。
