因为windows旧版控制台默认禁用ansi支持，需调用setconsolemode启用enable_virtual_terminal_processing并配合setconsoleoutputcp(cp_utf8)才能生效。
为什么 std::cout 直接输出 ANSI 转义序列有时不显示颜色
Windows 控制台（尤其是旧版 cmd 和早期 PowerShell）默认禁用 ANSI 支持，\033[32m 这类序列会被原样打印或忽略。即使代码逻辑正确，你也可能只看到一堆乱码或纯白文字。
实操建议：
- 在程序开头调用
SetConsoleOutputCP(CP_UTF8)并启用虚拟终端处理：用SetConsoleMode(GetStdHandle(STD_OUTPUT_HANDLE), ENABLE_VIRTUAL_TERMINAL_PROCESSING)（仅 Windows） - 跨平台更稳妥的做法是检测环境：检查
getenv("TERM")是否存在、是否含"xterm"或"linux"；Windows 上可 fallback 到SetConsoleMode调用 - 避免硬编码
\033，用字符串常量如"\x1b[36m"更清晰，且部分编辑器对\033识别不稳定
如何用递归 + 缩进 + ANSI 控制树节点颜色层次
颜色不应只靠深度决定，而要区分节点类型（根/分支/叶）、状态（活跃/禁用/错误），否则视觉信息过载。比如根节点用亮白 "\x1b[1;97m"，子分支用青色 "\x1b[36m"，叶子用灰色 "\x1b[90m"，比全用 32m 更易读。
实操建议：
- 递归函数签名建议带参数：
print_node(const Node& n, int depth, bool is_last_sibling)，用于控制连接符（├─、└─）和缩进空格数 - 每层缩进用
std::string(depth * 4, ' ')，别用\t—— 不同终端 tab 宽度不一致，树形会错位 - ANSI 颜色必须成对出现：有
"\x1b[36m"就得跟"\x1b[0m"重置，否则后续所有输出都带色 - 若节点名含特殊字符（如
'['或'm'），需提前转义或过滤，否则会意外截断颜色控制
std::wcout 输出中文节点时颜色失效怎么办
Windows 下 std::wcout 和 ANSI 序列天生冲突：ANSI 是字节流协议，wcout 按宽字符发送，导致 \x1b 被拆成两个 wchar_t，控制序列损坏。现象是中文正常显示但无颜色，或直接崩溃。
实操建议：
- 统一用
std::cout+ UTF-8 字符串（u8"根节点"），并确保源文件保存为 UTF-8 无 BOM - Windows 上必须调用
SetConsoleOutputCP(CP_UTF8)，否则cout输出中文会成问号，哪怕颜色正常 - 不要混用
cout和wcout—— 一旦其中一个被使用，另一个会进入失败状态，后续输出静默丢弃 - 若必须用宽字符处理逻辑，颜色部分改用
WriteConsoleW手动写入 ANSI 字节（需先转换为 UTF-8 字节数组）
性能瓶颈常出现在字符串拼接而非 ANSI 本身
每行输出都做多次 std::string 拼接（缩进 + 颜色前缀 + 名称 + 颜色后缀 + 连接符），深度大时触发频繁内存分配。实测 500 节点树，拼接耗时可能超输出本身 3 倍。
实操建议：
- 用
std::ostringstream单次构建整行，避免临时string对象反复构造析构 - 预先计算好各层级的缩进字符串（如
static const std::vector<:string> INDENTS = {"", " ", " ", ...}</:string>），查表比运行时生成快 - 对只读节点结构，考虑把格式化结果缓存到
std::vector<:string></:string>，后续刷新只重绘变化行 - 调试时关掉颜色（定义宏
NO_COLOR），能快速判断是渲染慢还是逻辑慢
实际最难的是让不同终端对齐：macOS Terminal、iTerm2、VS Code 集成终端、Windows Terminal 表现略有差异，尤其是双宽字符（中文）和 ANSI 序列的组合宽度计算。别指望一次写完就全兼容，得在目标环境上真机测试。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
