Sublime Text 输出面板不支持CSS样式定制，其UI为硬编码原生组件；唯一可控的是通过sublime-build文件的file_regex、line_regex及shell_cmd等配置结构化输出内容。
先明确一个核心事实：Sublime Text 的输出面板（Build Results）本身并不支持 CSS 样式定制。所谓“自定义输出面板样式”，本质上是个伪命题——你无法改变它的字体、颜色、行高或背景。原因很简单，这个面板是硬编码的原生 UI 组件，根本没有对外暴露样式接口。
为什么 build_results.hidden-tmLanguage 文件改了没用
网上流传着一种说法：修改 Packages/Default/build_results.hidden-tmLanguage 文件，或者把主题文件复制到 User 目录，就能改变输出面板的样式。其实，这完全是个误解。这些操作顶多只能影响语法高亮（比如让错误行号变成红色），但绝对动不了面板本身的 UI 样式。因为 Sublime 的构建面板渲染机制绕过了常规的 syntax definition 和 color scheme。
- 修改
build_results.hidden-tmLanguage只会影响匹配到的 token（例如error、file、line-number）在编辑器内部的着色，对独立的输出面板无效。 - 即便你重载了语法定义或者重启了 Sublime，面板里的文字依然会使用固定的系统默认等宽字体、固定大小，行距也无法调整。
- 一个常见的“槽点”是：在深色主题下，输出面板的背景常常是浅灰色，跟编辑器的深色背景格格不入。这并非配置遗漏，而是设计上的限制。
真正能控制的只有内容格式：靠 sublime-build 文件的 variants 和 shell_cmd
既然样式改不了，那我们能做什么？答案是：控制输出面板显示什么内容以及如何解析这些内容。你可以干预的是“文本结构”，而非“视觉样式”。关键在于用好构建系统配置文件。几个要点：
file_regex这个参数决定了哪一行输出会被识别为可点击跳转的错误行。它的格式通常是类似^([^:]+):([0-9]+):?([0-9]+)?:? (.*)$这样的正则表达式。line_regex则用于匹配警告信息或普通的日志行。如果不手动指定，Sublime 可能不会去解析它们。- 在
shell_cmd命令中加上2>&1，可以确保标准错误输出（stderr）也能被捕获并显示在面板里。你还可以利用sed或awk等工具预处理输出，比如给所有行加上统一的前缀标识（如[JS]）。 - 需要警惕的是，尽量避免在命令末尾添加类似
| cat的管道操作，因为 Sublime 的输出解析器有时会因此丢失首行信息或导致匹配错位。
想让错误更醒目？用 result_file_regex + 自定义构建脚本
如果默认的正则表达式无法匹配你的构建工具输出（比如 TypeScript 的 tsc --watch 或者 Webpack 的详细日志），该怎么办？这时就必须自己动手，写一个包装脚本，把原始输出“翻译”成 Sublime 能够理解的标准化格式。举个例子：
#!/bin/bash # sa ve as ~/bin/tsc-sublime.sh tsc 2>&1 | sed -E 's/^(.*):([0-9]+):([0-9]+): error TS([0-9]+): (.*)$/::: [TS]/'
然后，在你的 .sublime-build 配置文件中这样调用它：
{
"shell_cmd": "~/bin/tsc-sublime.sh",
"file_regex": "^(.+):[0-9]+:[0-9]+: .*$",
"line_regex": "^([^:]+):([0-9]+):([0-9]+): (.*)$"
}
- 这里有个细节需要注意：
file_regex和line_regex必须配合使用。前者负责定位文件路径，后者则用于提取具体的行号、列号和错误消息。 - 另外，Sublime 不支持 PCRE 风格的正则，它只认 POSIX ERE（也就是
egrep那种风格）。所以，别用\K或者 lookahead 这类高级特性。 - 对于多行错误信息（比如 Python 的完整 traceback），输出面板的处理能力比较有限——它只按行解析，无法自动合并上下文，信息可能会被截断。
说到底，真正让人感到困惑的，往往不是“具体怎么配置”，而是最初误以为它“可以配置”。输出面板本质上就是一个只读的终端模拟器。你唯一能做的，就是通过精心构造输入，让它的显示内容变得更结构化、更易读——靠的是对输出内容的预处理和解析规则的定制，而不是改变它的外观样式。
