最稳妥的windows控制台文字着色方式是调用setconsoletextattribute api，需先用getstdhandle获取句柄、getconsolemode确认控制台有效，再传入位掩码颜色值（如foreground_red|foreground_intensity），且每次输出后须手动重置，重定向到文件时应降级为纯文本。
用 SetConsoleTextAttribute 改变 Windows 控制台文字颜色
Windows 控制台不支持 ANSI 转义序列（除非启用虚拟终端处理且系统版本 ≥ Win10 1607），直接输出 [31mkeyword[0m 大概率显示乱码或原样打印。最稳妥的方式是调用 Win32 API：SetConsoleTextAttribute。
它需要一个 HANDLE（通常用 GetStdHandle(STD_OUTPUT_HANDLE) 获取）和一个表示颜色的 WORD 值，比如 FOREGROUND_RED | FOREGROUND_INTENSITY 表示亮红色。
- 必须在每次输出前调用，颜色不会自动恢复 —— 忘了重置会导致后续所有文字都变色
- 颜色值不是 RGB，而是位掩码组合；
FOREGROUND_BLUE | FOREGROUND_GREEN是青色，不是“蓝+绿=黄” - 如果程序被重定向到文件（如
app.exe > out.txt），SetConsoleTextAttribute会失败，需先用GetConsoleMode检查是否真在控制台里
Linux/macOS 下用 ANSI 转义序列要检查 TERM 和是否为终端
Linux/macOS 默认支持 [33m 这类序列，但前提是：当前 stdout 确实连着终端，且 TERM 环境变量非空（比如 xterm-256color）。否则可能输出可见的转义字符，或者被静默丢弃。
推荐用 isatty(STDOUT_FILENO) 判断是否为终端，再决定是否启用高亮 —— 否则用户把输出管道给 grep 或重定向到日志时，会看到一堆 ^[[32m 类乱码。
立即学习“C++免费学习笔记（深入）”；
-
[1m是加粗，[38;5;172m是 256 色模式下的橙色，但老终端可能只认 16 色（[31m～[37m） - 高亮关键词前后必须用
[0m重置，否则影响后续所有输出；别漏掉末尾的重置 - C++ 字符串字面量里写
"[32m"没问题，但若用std::string拼接，注意不要误把当成字符串结束符（它只是 ASCII 27，不是
跨平台封装时，别硬写 if-else 判系统宏
直接 #ifdef _WIN32 / #else 容易漏掉 Cygwin、MSYS2 这类“Windows 上的类 Unix 环境”，它们支持 ANSI 但定义了 _WIN32。更可靠的做法是运行时检测：
- 先调
isatty(STDOUT_FILENO)—— 所有 POSIX 系统都支持，Windows 的 MinGW/MSVC 运行时也提供该函数 - Windows 上再额外调
GetConsoleMode确认句柄有效；失败就退回到纯文本 - 避免在头文件里暴露 Win32 类型（如
HANDLE），把平台相关代码封进 .cpp 文件里
例如封装一个 highlight(const std::string& text, const std::string& keyword, Color c) 函数，内部按需选 ANSI 或 API 调用，上层完全无感。
正则匹配关键词时，std::regex 在 MSVC 上性能差、不支持 边界
想高亮 “cat” 但不匹配 “scattered”，得用单词边界。GCC/libstdc++ 和 Clang/libc++ 的 std::regex 支持 \bcat\b，但 MSVC 的实现直到 VS2019 16.10 才修复 \b 行为，早期版本会静默忽略或匹配错误。
- 简单场景直接用
std::string::find()循环查找更稳，自己判断前后字符是否为非字母数字（!isalnum(prev)&&!isalnum(next)） - 若必须用正则，Windows 下可换
boost::regex或 C++17 的std::string_view+ 手动扫描 - 注意大小写：默认
std::regex区分大小写，std::regex_constants::icase在各平台行为一致，但编译耗时明显增加
高亮本身不难，难的是让颜色在各种终端、重定向、CI 日志环境里都不崩 —— 最容易被忽略的，其实是“不渲染”的情况：当输出目标不是交互式终端时，安静地退回纯文本，比强行塞颜色更专业。
