SetConsoleTextAttribute是Windows下唯一稳定、无需第三方库的控制台颜色控制方案，需先获取标准输出句柄并传入合法属性值，属性按位或组合且前景色占低4位、背景色占高4位。
Windows下用SetConsoleTextAttribute改颜色最直接
在Windows平台，控制台颜色控制依赖WinAPI，SetConsoleTextAttribute是唯一稳定、无需第三方库的方案。它作用于当前控制台句柄，影响后续所有输出，不是“给某段文字上色”，而是切换输出笔刷状态。
常见错误是调用后立刻std::cout没生效——忘了先用GetStdHandle(STD_OUTPUT_HANDLE)获取句柄，或传入了非法属性值（比如把FOREGROUND_RED | BACKGROUND_GREEN写成1 | 2但漏掉高位背景位）。属性值是按位或组合，前景色低4位、背景色高4位，比如红字绿底是FOREGROUND_RED | BACKGROUND_GREEN（即4 | 2 = 6），但纯绿色背景其实是BACKGROUND_GREEN（2 32）。
实操建议：
- 始终检查
GetStdHandle返回值是否为INVALID_HANDLE_VALUE - 恢复默认色用
FOREGROUND_RED | FOREGROUND_GREEN | FOREGROUND_BLUE（白字），不是0 - 避免在多线程中频繁切换——不同线程共用同一控制台，可能互相覆盖颜色状态
Linux/macOS用ANSI转义序列，但要注意终端兼容性
Unix系系统不认WinAPI，靠ANSI ESC序列，格式是\033[<em>code</em>m，其中code是数字组合。比如\033[31m是红字，\033[42m是绿底，\033[0m重置。
立即学习“C++免费学习笔记（深入）”；
问题常出在：终端不响应（如某些IDE内置终端禁用ANSI）、误写成\e而非\033（后者更跨平台）、忘记重置导致后续所有输出变色。macOS的Terminal.app默认支持，但VS Code的集成终端需确认设置里terminal.integrated.enableColorization为true。
实操建议：
- 优先用
\033而非\x1b或\e，兼容性更好 - 组合样式时用分号连接，如
\033[1;33;40m（粗体黄字黑底） - 生产环境若不确定终端能力，先检测
isatty(STDOUT_FILENO)再输出ESC序列
C++跨平台封装要绕开system("color")
system("color 0A")看似简单，但它是调用cmd.exe的外部命令，有启动开销、无法精确控制单行、且Linux下根本不存在color命令。更糟的是，它会重置整个控制台颜色，破坏之前设置的状态。
真正跨平台的做法是运行时检测平台：#ifdef _WIN32走SetConsoleTextAttribute，否则用ANSI序列。别试图用conio.h（已废弃）或Boost.Process（过度设计）。
实操建议：
- 封装成一个
set_console_color(int fg, int bg)函数，内部按平台分支 - Windows分支里，
bg为-1时只设前景色，避免意外覆盖背景 - 避免宏定义颜色常量（如
RED=31），直接用enum class Color { Red = 31, ... }提高可读性
颜色失效？先查这三件事
颜色没反应，90%不是代码错，而是环境或逻辑问题。
排查顺序：
- 输出是否被重定向？
./a.out > out.txt时ANSI序列会写入文件，但不会渲染；Windows下重定向到文件同样失效 - IDE终端是否禁用颜色？CLion默认开启，但某些远程SSH会话的
$TERM设为dumb，ANSI被忽略 - 是否在
std::endl之后才调用颜色函数？颜色状态只影响之后的输出，之前已刷出的内容不受影响
最隐蔽的坑：C++流缓冲。如果用了std::ios_base::sync_with_stdio(false)，又混用printf和std::cout，ANSI序列可能被缓冲乱序，导致颜色错位。保持I/O方式统一。
