sublime text构建系统不负责高亮错误行，真正实现错误行标红的是error_regex解析机制+语法作用域匹配+配色方案渲染；任一环节缺失或配置错误（如正则不匹配、file_regex未设、working_dir错误、主题未定义markup.error等），都会导致错误信息仅显示为普通文本而无法高亮或跳转。
Sublime Text 的构建系统本身不负责语法高亮，也不会“高亮错误行”——它只执行命令、捕获输出；真正把错误定位到某行并标红的，是 Sublime 内置的 error_regex 解析机制 + 语法作用域（scope）匹配 + 配色方案渲染。配置错或缺失任一环，错误行就只是文本，不会变红。
为什么 build 输出里有 error 但行没变红
常见现象：运行 bazel build // 或 dotnet fsi 后控制台打印了 ERROR: /path/to/file.fs:12:5: ...，但第 12 行没高亮，光标也没跳转。
-
error_regex没配或格式不匹配：Sublime 默认只识别极简格式（如^([^:]+):([0-9]+):([0-9]+):），而 Bazel、F#、Nim 等工具的错误格式各不相同，必须手动适配 - 构建系统没设
file_regex：这个字段决定点击错误行时跳转到哪个文件，若为空，即使解析成功也无法跳转 - 输出不是标准错误流（stderr）：某些工具把错误写进 stdout，而 Sublime 默认只解析 stderr；需加
"quiet": false并确认输出流向 - 配色方案未启用
invalid.illegal或markup.errorscope 渲染：有些主题刻意隐藏错误标记，导致“解析了但看不见”
error_regex 怎么写才匹配真实错误格式
以 F# 脚本报错为例：/path/to/script.fsx(42,10): error FS0039: The value or constructor 'xxx' is not defined.
对应正则应为："error_regex": "^([^(]+)((d+),(d+)): error [A-Z]{2}d+: .*$"
- 第一组
([^\(]+)提取文件路径（直到第一个(） - 第二组
(\d+)提取行号，第三组提取列号 - 必须用双反斜杠
\(转义括号，单反斜杠在 JSON 字符串里会被吃掉 - 结尾
.*$兜底任意后续内容，避免因消息变动导致整行不匹配 - Bazel 常见格式：
ERROR: /a/b/c/BUILD:23:14: ...→ 正则："error_regex": "^ERROR: ([^:]+):([0-9]+):([0-9]+):.*$"
构建系统必须同时配 file_regex 和 working_dir
仅靠 error_regex 解析出路径还不够——如果路径是相对的（如 src/main.fs），Sublime 需知道从哪开始找。这时 file_regex 和 working_dir 必须协同：
-
"file_regex": "^(.+?):([0-9]+):([0-9]+):"：和error_regex类似，但只负责提取可跳转的文件路径（不含行/列） -
"working_dir": "$project_path"：确保相对路径基于项目根解析；若误设为$file_path，而当前打开的是子目录文件，就会找不到src/main.fs - 若错误中路径已是绝对路径（如
/home/user/proj/src/main.fs），file_regex可简化为"^(.+?):[0-9]+:[0-9]+:"，working_dir影响不大
错误行变红但不跳转？检查 scope 和主题是否支持
Sublime 把匹配到的错误行标记为 markup.error 或 invalid.illegal scope，最终颜色由当前 color scheme 决定。如果主题没定义这两个 scope，或者设成了透明色，就会“解析成功但不可见”。
- 临时验证：打开一个已知报错的文件 → 运行构建 → 点击控制台里的错误行 → 观察是否跳转；若跳转但无高亮，大概率是主题问题
- 快速切换主题测试：菜单 Preferences → Color Scheme → Brogrammer（该主题明确渲染
invalid.illegal） - 不建议直接改主题文件；更稳妥的是在构建系统里加
"variants"并设"target": "exec"，确保走标准错误解析流程
最容易被忽略的是：即使 error_regex 完全正确，如果构建命令本身没触发 stderr 输出（比如加了 --quiet 或重定向了输出），Sublime 就根本收不到原始错误流——此时所有正则都白配。
