setw只对下一个输出项生效，非全局设置或对齐开关；常见错误是误以为它能持续影响后续输出。
setw 为什么总不生效？
因为 setw 只对「紧接着的下一个输出项」起作用，不是设置全局宽度，也不是“打开对齐开关”。它本质是个临时格式修饰符，用完即丢。
常见错误现象：cout 期望 <code>"b" 也占 10 位，结果只有 "a" 被填充空格，"b" 紧跟其后毫无对齐——这是最常踩的坑。
- 每次需要对齐，都得在对应输出项前重新写一次
setw(n) - 必须搭配
ios::left/ios::right（默认右对齐）才看得出效果；光setw不设对齐方式，只是预留宽度，内容仍靠右 - 如果输出项本身长度 ≥
setw设的值，setw直接失效，原样输出（不截断也不缩放）
怎么让多列数字/字符串整齐对齐？
典型场景：打印表格、日志、调试输出。关键不是堆 setw，而是「每列单独控制」+「统一补空格方向」。
示例：两列整数，左列宽 8、右对齐；右列宽 12、左对齐：
立即学习“C++免费学习笔记（深入）”；
cout << setw(8) << right << 123
<< setw(12) << left << "hello"
<< endl;
注意：right 和 left 是流操纵器，会持续生效，直到被另一个对齐操纵器覆盖。所以如果后续还要右对齐，得再写一次 right。
- 别混用
left和right在同一行又不重置，容易导致后面输出意外左对齐 - 字符串含中文时，
setw按字节数计宽（UTF-8 下一个汉字占 3 字节），视觉上会错位；此时应改用固定宽度的等宽字体 + 英文空格填充，或换用更可控的格式化库 - 数值类型（如
int、double）用setw安全；但std::string若含 \0 或非 ASCII 字符，长度计算可能和显示宽度不一致
替代方案：什么时候不该硬扛 setw？
当输出结构变复杂（比如动态列数、嵌套字段、需要千分位或小数位控制），setw 就开始力不从心了。它不保存状态，不支持嵌套，也没法回退。
性能与兼容性影响很小——setw 是纯前端格式控制，不涉及内存分配或系统调用。但它依赖 <iomanip></iomanip>，且只对 std::ostream 有效，对 C 风格 printf 或文件写入无效。
- 简单日志、调试打印，
setw够用；但生成报告或导出 CSV，优先考虑fmt::format或std::format（C++20） - 需要精确控制小数位时，
setprecision必须和fixed/scientific配合，单用setw不影响浮点精度 - 跨平台输出对齐时，注意终端是否支持等宽字体——
setw生效的前提是显示层不把空格压缩或忽略
