std::setw和std::setfill仅对下一次流输出生效，不能直接与字符串拼接；字符串对齐需手动实现左右补字符，且Unicode场景下须用字符宽度而非字节长度。
用 std::setw 和 std::setfill 做基础宽度填充，但必须配合流操作符
单纯调用 std::setw(n) 不会修改字符串本身，它只对紧随其后的下一次输出操作生效，且仅作用于 std::cout 或其他流对象。常见错误是写成：std::setw(10) + str 或 str = std::setw(10) + str——这根本不会编译，因为 std::setw 返回的是一个格式化操纵器（std::ios_base& 类型），不能和 std::string 直接拼接。
正确做法是把字符串送入流中处理：
std::ostringstream oss;
oss << std::setw(10) << std::setfill('0') << 42;
std::string result = oss.str(); // "0000000042"注意三点：
-
std::setw是一次性生效，每次输出前都得重设 -
std::setfill会持续生效，直到再次调用它改变填充字符 - 左对齐需额外加
std::left，右对齐用std::right（默认），居中无标准库支持
手写居中对齐函数：计算左右填充长度是关键
标准库不提供居中填充，必须自己算。核心逻辑是：总宽减去原串长，再平分给左右；若差值为奇数，多出的那一个空格通常放右边（更符合视觉习惯）。
立即学习“C++免费学习笔记（深入）”；
示例实现：
std::string center(const std::string& s, size_t width, char fill = ' ') {
if (s.length() >= width) return s;
size_t pad = width - s.length();
size_t left = pad / 2;
size_t right = pad - left;
return std::string(left, fill) + s + std::string(right, fill);
}容易踩的坑：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 没检查
s.length() >= width，导致pad成为极大正整数（size_t下溢） - 误用
(pad + 1) / 2算左边——这会让左边多一格，不符合多数排版惯例 - 用
std::string(width - s.size(), ' ')直接拼接却不处理width < s.size()的情况
避免临时 std::ostringstream 开销：用 std::string 构造填充
高频调用时，反复构造/析构 std::ostringstream 有明显性能代价。更轻量的做法是直接构造字符串：
右对齐（末尾补空格）：
std::string right_align(const std::string& s, size_t width, char fill = ' ') {
if (s.length() >= width) return s;
return std::string(width - s.length(), fill) + s;
}左对齐（开头补空格）：
std::string left_align(const std::string& s, size_t width, char fill = ' ') {
if (s.length() >= width) return s;
return s + std::string(width - s.length(), fill);
}对比流式方案：
- 构造字符串方式零流状态、无 locale 影响、无缓冲区管理开销
- 但不支持
std::hex/std::scientific等数值格式化——仅适用于纯字符串或已格式化好的内容 - 若需混合数字+对齐（如
"ID: " + right_align(std::to_string(id), 4)），先转字符串再对齐更可控
Unicode 字符串对齐失效？别用 length() 当显示宽度
std::string::length() 返回字节数，不是显示宽度。含中文、emoji 或组合字符时，一个字符可能占多个字节，但只占一个“格子”。比如 "你好" 的 length() 是 6（UTF-8 编码），但显示宽度是 2。
真正做终端对齐或表格排版时，必须用 Unicode 字符宽度计算（如 ICU 库的 u_strlen + u_getIntPropertyValue，或轻量方案如 utf8cpp 的 utf8::distance）。否则：
- 按字节宽填充会导致中文被截断或错位
- emoji（如 ?）可能被拆成多个无效 UTF-8 字节
- 制表符
'\t'在不同终端展开宽度不一，不应参与对齐计算
简单项目可先限定 ASCII 场景；一旦涉及多语言，就得引入专用宽度测量逻辑——这点常被忽略，直到上线后发现日志表格彻底错行。
