Windows下应优先用SetConsoleTextAttribute配合GetStdHandle实现颜色控制，Linux/macOS用ANSI转义序列；需运行时探测终端能力并支持重定向降级，且提供NO_COLOR环境变量等可配置开关。
Windows下用SetConsoleTextAttribute控制颜色
Windows原生控制台不支持ANSI转义序列（除非启用VT100模式且系统版本≥Win10 1607），更稳妥的方式是调用WinAPI。关键函数是SetConsoleTextAttribute，它需要一个HANDLE（通常用GetStdHandle(STD_OUTPUT_HANDLE)获取）和一个WORD颜色值。
颜色值由前景色（低4位）和背景色（高4位）组成，例如FOREGROUND_RED | FOREGROUND_INTENSITY表示亮红色文字。注意：默认控制台句柄可能被重定向（如管道或重定向到文件），调用前建议用GetConsoleScreenBufferInfo确认是否为真实控制台，否则会静默失败。
- 必须在每次输出前设置，颜色不会自动继承到下一行
-
SetConsoleTextAttribute只影响后续输出，已打印的内容不可修改 - 若程序以非控制台子系统（
/SUBSYSTEM:WINDOWS）链接，GetStdHandle可能返回INVALID_HANDLE_VALUE，需提前判断
Linux/macOS用ANSI转义序列输出颜色
绝大多数POSIX终端支持CSI（Control Sequence Introducer）序列，格式为\033[m，其中是数字组合，如31代表红色前景，42代表绿色背景，多个代码可用分号连接（如31;47是红字白底）。
常见代码：30–37（前景色）、40–47（背景色）、1（高亮）、22（取消高亮）、0（重置所有属性）。注意：这些序列是纯文本，无平台API依赖，但需确保输出流未被重定向到非终端设备（如文件或管道），否则会直接打印乱码。
立即学习“C++免费学习笔记（深入）”；
- 用
isatty(STDOUT_FILENO)判断stdout是否连到终端，避免向文件写入ANSI码 - 某些老旧终端（如部分嵌入式minicom）不支持
1（bold），可降级为2（dim）或忽略 - macOS Terminal和iTerm2默认支持，但Alacritty、kitty等现代终端还支持256色（
38;5;N）和真彩色（38;2;R;G;B），不过跨平台封装时建议先守住基础16色
如何统一接口并自动检测运行环境
核心思路是封装一个ColorPrinter类或一组自由函数，在首次调用时探测平台和终端能力，之后按需分发。不要在编译期硬编码#ifdef _WIN32——因为Windows Subsystem for Linux（WSL）下_WIN32仍定义，但实际应走ANSI路径；同理，macOS上__linux__未定义，但终端行为与Linux一致。
运行时探测更可靠：getenv("TERM")非空 + isatty(STDOUT_FILENO)为真 → 启用ANSI；否则在Windows上尝试GetStdHandle + GetConsoleMode确认是否为控制台句柄。
- 避免重复探测：用静态局部变量或
std::call_once保证初始化只执行一次 - 不要假设
TERM值含义——xterm-256color和screen都支持ANSI，只需确认存在且非dumb - Windows 10 1511+可通过
SetConsoleMode(hOut, ENABLE_VIRTUAL_TERMINAL_PROCESSING)开启ANSI支持，但需管理员权限或特定组策略，不如原生API稳定，不推荐作为首选
封装时绕不开的细节：重定向与缓冲区
颜色控制本质是向输出流注入控制字符或调用系统API，一旦stdout被重定向（如./app > out.txt），ANSI序列会污染日志，而Windows API调用则直接失效。因此，任何健壮的封装都必须把“是否启用颜色”做成可配置的运行时开关，而非仅靠环境探测。
典型做法：提供enable_color(bool)接口，并默认根据终端探测结果设为true；同时允许用户通过环境变量（如NO_COLOR=1）或命令行参数强制关闭——这是no-color.org倡导的通用约定，已被curl、pip等广泛采用。
-
std::cout默认行缓冲，但插入ANSI序列后可能破坏对齐逻辑，尤其配合std::left/std::setw时 - Windows API方式无法与
std::wcout混用（宽字符控制台需额外处理），建议统一用窄字符输出 - 多线程环境下，不同线程交替调用颜色打印可能导致样式错乱，需加锁或要求用户自行同步
