linux终端彩色文字依赖ansi转义序列解析，非语言或系统特性；输出重定向至文件会原样保存序列致乱码，精简终端可能不支持，需确认term值并用\033[0m重置，\033、\x1b、\e等效但\033兼容性最佳，printf与std::cout无本质区别。
\033[32m 这类字符串，终端就会渲染绿色，不依赖 C++/Python 任何特性。
为什么 std::cout 有时没颜色？
最常见原因是终端不识别或输出被重定向了：
-
./a.out > log.txt会把\033[31m原样写进文件，打开看就是乱码，不是“没生效” - 某些精简终端（如
busybox ash、容器里最小化镜像的sh）压根不支持 ANSI，得换bash或确认$TERM是xterm-256color等标准值 - 忘记加
\033[0m重置，后续所有输出都带红字，容易误判为“第一次就不生效” - 用
\e或\x1b替代\033时，部分老编译器（如旧版 GCC）不支持\e，优先用\033
printf 和 std::cout 输出颜色有区别吗？
没有本质区别，都是往 stdout 写字节流。但要注意缓冲和换行行为：
-
printf("\033[32mOK\n\033[0m")——\n触发行缓冲，颜色能立刻看到 std::cout —— <code>std::endl强制刷新，安全；但若漏掉，又没手动 <code>std::cout.flush()，可能卡住不显示- 混用时别交叉：比如
printf后紧跟std::cout，不同缓冲策略可能导致顺序错乱（虽少见，但调试日志时可能踩坑）
怎么避免每次手拼 \033[... 容易出错？
封装成函数最轻量，C++ 可直接 inline：
inline std::string red(const std::string& s) { return "\033[31m" + s + "\033[0m"; }
inline std::string bold_green(const std::string& s) { return "\033[1;32m" + s + "\033[0m"; }
// 使用
std::cout
<p>关键点：</p>
- 必须在返回字符串末尾加
\033[0m，否则调用者不用管重置 - 组合调用如
red(bold_green("X"))也有效，因为内层先加\033[0m，外层再包一层，最终只留最外层的重置 - 不要用宏（如
#define RED(s) "\033[31m"s"\033[0m"），C++11 后字符串字面量不能直接拼接变量
哪些颜色代码实际可用？别记错范围
基础 8 色足够日常，高亮色（90–97）和 256 色需终端明确支持，别默认启用：
- 前景色：固定用
30–37（黑、红、绿、黄、蓝、洋红、青、白） - 背景色：固定用
40–47（对应同名色） - 加粗：
1（多数终端显示为“亮色”，不是真正加粗字体） - 慎用
90–97：虽然叫“亮色”，但有些终端（如 tmux 默认配置）会把它映射成基础色，反而看不出区别 - 256 色（如
\033[38;5;196m）要查表，且必须确认$TERM支持，普通脚本不建议硬编码
docker logs 都可能过滤或忽略控制字符。如果输出目标不确定，宁可先用纯文本加前缀（如 [ERROR]），再按需开启颜色。
