终端字符宽度≠字符数，需用wcwidth()计算UTF-8字符串真实列宽，结合ioctl获取终端宽度、剔除ANSI序列与控制字符，并按字节索引安全切分以避免中文/Emoji断开。
终端字符宽度 ≠ 字符数，中文和 Emoji 会出问题
直接用 std::string::length() 切分字符串必然错——ASCII 字符占 1 个终端列宽，而 UTF-8 编码的中文字符（如 "你好"）在终端里通常占 2 列，Emoji（如 "?"）可能占 1 或 2 列，甚至有些组合字符（如带修饰符的肤色 Emoji）宽度更难预测。Linux/macOS 的 wcwidth() 函数是标准解法，但它只处理宽字符（wchar_t），需要先将 UTF-8 字符串转成宽字符串。
实操建议：
- 用
std::mbstowcs()将 UTF-8std::string转为std::wstring，注意检查返回值是否为 -1（转换失败） - 对每个
wchar_t调用wcwidth(c)：返回 -1 表示非打印字符，0 表示零宽（如 ZWJ、变体选择符），1 或 2 表示正常显示宽度 - 别忽略控制字符：ANSI 转义序列（如
"\033[1m"）本身不占显示宽度，但必须从宽度计算中剔除，否则换行位置偏移
按终端列宽切分字符串时，如何避免在中文/Emoji 中间断开
不能简单按累计宽度 >= 目标列宽就切，因为一个字符可能跨列（如宽度为 2 的汉字），强行在它前面切会导致上一行末尾留空、下一行开头突兀；更糟的是在 Emoji 组合内部切断（如 "??" 是多个 Unicode 码点拼成的），会显示为乱码或异常符号。
实操建议：
- 逐字符累加宽度，但每次累加前先预判：若当前字符宽度 + 已有宽度 > 目标列宽，且已有宽度 > 0，则在此处换行（即不把当前字符塞进本行）
- 对宽度为 0 的字符（如
'\t'、ZWJ），跳过宽度累加，但保留在原位置输出（它们影响渲染但不占列） - 遇到宽度为 -1 的字符（无效或控制字符），跳过计算，但保留原字节写入输出流（否则 ANSI 颜色失效）
- 用
std::string::substr()切分时，必须基于原始 UTF-8 字节索引，而不是wchar_t索引——推荐边遍历宽字符边维护对应 UTF-8 字节偏移表
Linux/macOS 下获取终端列宽的可靠方式
ioctl(STDOUT_FILENO, TIOCGWINSZ, &w) 是最准的，比读取 $COLUMNS 环境变量或硬编码 80 更可靠，尤其在重定向输出或管道场景下，$COLUMNS 可能为空或错误。
实操建议：
- 封装一个
get_terminal_width()函数，失败时 fallback 到 80（不是 0 或 -1） - 注意：当 stdout 不是终端（如重定向到文件或管道）时，
ioctl会失败，此时不应强制换行——可加一个isatty(STDOUT_FILENO)判断 - 别在循环里反复调用：终端大小变化不频繁，首次获取后缓存即可；如需响应
SIGWINCH，需另设信号处理，一般 CLI 工具无需这么复杂
实际排版函数要处理的边界情况
一个可用的 wrap_text(const std::string& s, int width) 函数，至少得扛住这些：
- 输入含换行符
'\n'：应保留原有换行，只对每行内部做自动换行 - 单个单词超长（如一长串 URL）：不能卡死，需强制在
width处切断（即使中间是中文），否则无限循环 - 全角空格（
" "）和半角空格（' '）宽度不同，但都应作为潜在断点；但不要在行首或行尾保留孤立空格 - 制表符
'\t'：按 4 或 8 列展开，但展开后若超出当前行剩余宽度，应整体移到下一行（而非部分展开）
最易被忽略的是：换行逻辑必须和最终输出解耦——计算出每行的 UTF-8 字节范围后，再统一拼接换行符，而不是边算边输出。否则嵌入 ANSI 转义序列时，颜色代码可能被截断，导致后续文本染色异常。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
