终端色彩渲染是 CLI 工具、终端 UI 框架和日志系统的核心技术基础。ANSI 标准最初仅支持 8 种基础颜色（索引 0-7）及其高亮版本（索引 8-15），远远无法满足现代终端应用的色彩需求。256 色 Palette 作为 ANSI 扩展的重要里程碑，通过索引映射的方式在有限带宽下实现了更丰富的色彩表达。本文将从色彩空间映射的数学原理出发，给出完整的算法实现与工程参数。
256 色 Palette 的索引结构
终端 256 色 Palette 将索引空间 0-255 划分为三个明确的区域，每个区域对应不同的色彩生成策略。索引 0-7 是标准 ANSI 基础色，涵盖黑、红、绿、黄、蓝、品、青、白八种颜色；索引 8-15 是高强度版本，通过增加亮度属性实现基础色的视觉增强；索引 16-231 构成 6×6×6 的 RGB 彩色立方体，共 216 种颜色；索引 232-255 则是 24 级灰度渐变，从近乎黑色过渡到近乎白色。这种结构设计兼顾了兼容性（基础 16 色保持不变）与扩展性（216 色立方体 + 24 级灰度），是工程实践中被广泛采用的折中方案。
理解这一索引分布对于正确生成 Palette 至关重要。不同的终端模拟器（如 xterm、iTerm2、Windows Terminal）在基础 16 色的定义上可能存在细微差异，但索引 16 以上的生成规则基本遵循 xterm 规范，这为跨平台实现提供了稳定的数学基础。
6×6×6 RGB 彩色立方体算法
RGB 彩色立方体是 256 色 Palette 的核心组成部分，其索引映射遵循简洁而优美的数学公式。对于任意一组坐标（r, g, b），其中 r、g、b 均取自集合 {0, 1, 2, 3, 4, 5}，对应的 Palette 索引计算公式为：
index = 16 + 36 × r + 6 × g + b
这一公式的推导逻辑清晰：r 分量占 36 个索引宽度（6×6），g 分量占 6 个索引宽度，b 分量占 1 个索引宽度。从 r=0、g=0、b=0 对应的索引 16 开始，r 每递增 1 就跳過 36 个索引位置，g 每递增 1 就跳過 6 个位置，b 直接线性递增。实际工程中，通常采用三层嵌套循环遍历这三个维度，依次生成 216 个颜色值。
然而，仅有坐标（r, g, b）还不够 —— 需要将离散的 0-5 级别映射到真实的 8 位 RGB 通道值。xterm 规范定义的标准映射表将 6 个级别映射为 [0, 95, 135, 175, 215, 255] 这六个离散值。这种非均匀离散化设计考虑了人眼对亮度变化的非线性感知特性，使得渐变过渡更加平滑自然。级别 0 对应纯黑（RGB=0,0,0），级别 5 对应纯白（RGB=255,255,255），中间四个级别则均匀覆盖了暗部到亮部的过渡区域。
具体的颜色生成伪代码如下：首先定义通道级别数组 steps = [0, 95, 135, 175, 215, 255]，然后从索引 16 开始依次填充。对于每个 r 从 0 到 5、g 从 0 到 5、b 从 0 到 5 的组合，计算得到对应索引 index = 16 + 36r + 6g + b，并将该索引的 RGB 分量分别设置为 steps [r]、steps [g]、steps [b]。这样即可得到完整的 216 色立方体映射表。
灰度渐变生成算法
索引 232-255 的 24 级灰度渐变是 256 色 Palette 中最简单的部分，其映射关系呈完美的线性特征。计算公式为：
value = 8 + 10 × gray_index
其中 gray_index 的取值范围是 0 到 23，对应索引 232 到 255。当 gray_index 为 0 时，value = 8，产生近乎黑色的 RGB (8, 8, 8)；当 gray_index 为 23 时，value = 8 + 230 = 238，产生近乎白色的 RGB (238, 238, 238)。这种从 8 开始到 238 结束的灰度范围避免了纯黑（0）和纯白（255）与基础 16 色中的黑色和白色产生完全重叠，保留了视觉层次上的区分度。
灰度渐变的生成可以直接通过单层循环实现，遍历 i 从 0 到 23，计算 value = 8 + 10 * i，然后将索引 232+i 的 RGB 分量统一设置为 (value, value, value) 即可。
ANSI 转义序列工程实践
在终端中输出 256 色需要构造特定的 ANSI SGR（Select Graphic Rendition）转义序列。标准格式为：前景色使用\x1b[38;5;Nm，背景色使用\x1b[48;5;Nm，其中 N 是 0-255 的 Palette 索引值。转义序列以 ESC 字符（ASCII 码 27，十六进制 0x1B）开头，左方括号后跟随参数代码，末尾以小写字母 m 作为终止符。
典型的工程实现中，通常会定义颜色重置序列\x1b[0m用于恢复默认样式。在输出彩色文本时，常见的模式是在文本前插入前景色转义序列，在文本后插入重置序列以避免颜色泄漏影响后续输出。例如，输出索引 196 的红色文本需要构造字符串"\x1b[38;5;196m红色文本\x1b[0m"。如果需要同时设置前景色和背景色，可以将两个转义序列连续放置，如"\x1b[48;5;21m\x1b[38;5;231m蓝色背景白色文字\x1b[0m"。
在性能敏感的批量渲染场景下（如渲染大型表格或进度条），建议预先计算并缓存常用的转义序列字符串，而非在每次输出时重新拼接。此外，某些终端模拟器支持将多个 SGR 参数合并到单个转义序列中（如\x1b[38;5;196;48;5;21m），可以略微减少转义序列的总长度。
与 TrueColor 的对比及工程选型
现代终端还支持 TrueColor（24 位真彩色），其转义序列格式为\x1b[38;2;R;G;Bm（前景色）或\x1b[48;2;R;G;Bm（背景色），直接编码 RGB 三个通道的 0-255 值。从功能角度看，TrueColor 可以表达约 1677 万种颜色，远超 256 色的有限集合，在渲染照片级图像、复杂渐变和精确品牌色时具有明显优势。
然而，在工程实践中，两者的性能差异微乎其微。现代终端模拟器的渲染瓶颈主要在于字体光栅化、GPU 合成和窗口管理等方面，转义序列的解析开销在整个渲染流水线中几乎可以忽略。256 色模式的转义序列确实更短（前者如\x1b[38;5;123m约 9 字节，后者如\x1b[38;2;255;0;0m约 16 字节），但在网络传输或高频率刷新的极端场景下，这种差异才可能累积为可感知的影响。
兼容性是选择 256 色的重要考量因素。较老的终端模拟器、TTY 模式、SSH 远程会话等环境中，256 色支持的普及度远高于 TrueColor。部分终端通过环境变量COLORTERM来声明真彩色支持，值为truecolor或24bit表示支持。工程实践中，可以通过检测该环境变量来动态选择使用 256 色索引模式还是直接 RGB 模式，在兼容性与色彩精度之间取得平衡。
综合以上分析，建议的工程参数如下：在终端能力检测通过的情况下优先使用 TrueColor 以获得最精确的色彩表现；对于需要跨平台一致性的工具类应用、提供预制主题的终端 UI 框架、或在受限网络环境下传输大量彩色数据时，使用 256 色索引模式；无论选择哪种模式，都应提供配置选项允许用户回退到更保守的色彩方案。
参考资料
- ANSI Escape Codes, GitHub Gist: https://gist.github.com/fnky/458719343aabd01cfb17a3a4f7296797
- How to Use 256 Colors in ANSI Escape Codes, Colorist for Python: https://jakob-bagterp.github.io/colorist-for-python/ansi-escape-codes/extended-256-colors/