std::setw和std::setfill仅支持单向填充，无内置双向填充；需手动计算左右填充长度：右对齐右补、左对齐左补、居中则左右均分。
用 std::setw 和 std::setfill 做基础单向填充，但默认不支持“双向”语义
标准库没有叫“双向填充”的现成工具——所谓“双向”，其实是“左对齐时右补、右对齐时左补、居中时左右均分补”，而 std::setw + std::setfill 只控制宽度和填充字符，对齐方向由 std::left/std::right/std::internal 决定，std::internal 仅对带符号数值有效，对字符串无效。
所以必须自己算左右填充长度。关键判断逻辑是：target_width 时直接输出原串（不截断），否则按对齐方式分配空格（或指定填充符）到左右两侧。
实操建议：
- 先用
str.length()获取原始长度，避免误用c_str()+strlen（对含\0的字符串出错） - 填充字符默认用空格，但应允许传入任意
char（比如'*'或'='） - 居中对齐时，左侧填充数 =
(target_width - str.length()) / 2，右侧自动补足；整除时左少右多（更符合视觉习惯），可选是否向上取整
手写 pad_string 函数处理居中与双侧填充
标准流操纵器无法居中字符串，最稳妥的方式是返回新 std::string。下面是一个轻量实现：
立即学习“C++免费学习笔记（深入）”；
#include <iomanip>
#include <string>
#include <cmath>
<p>std::string pad_string(const std::string& s, size_t width, char fill = ' ',
const std::string& align = "left") {
if (s.length() >= width) return s;
size_t pad_total = width - s.length();
size_t left_pad = 0, right_pad = 0;
if (align == "left") {
right_pad = pad_total;
} else if (align == "right") {
left_pad = pad_total;
} else if (align == "center") {
left_pad = pad_total / 2;
right_pad = pad_total - left_pad; // 左右不等时，右边多1
}
return std::string(left_pad, fill) + s + std::string(right_pad, fill);
}</p>注意点：
-
std::string(n, c)构造效率高，比循环 push_back 快得多 - 不要用
std::string::insert(0, n, c)多次修改，会触发多次内存重分配 - 如果对性能极端敏感（如日志高频调用），可预先 reserve 容量：
result.reserve(width)
用 std::format（C++20）简化对齐，但居中仍需手动
C++20 的 std::format 支持 {:>10}（右对齐）、{:（左对齐）、<code>{:^10}（居中），看起来能直接替代：
std::string s = "hi";
std::string out = std::format("{:^10}", s); // → " hi "
但它有明显限制：
- 不支持自定义填充字符（
{:*^10}是非法的；C++23 才加入填充符支持） - 格式字符串解析有运行时开销，不适合嵌入 tight loop
- 某些旧编译器（如 GCC 12 默认未启用
std::format）需加-std=c++20 -lstdc++fs
所以除非你已全面迁移到 C++23 且只用空格填充，否则手写 pad_string 更可控。
输出到 std::cout 时避免流状态污染
如果在流式输出中混用 std::setw 和手动拼接，容易踩坑：
-
std::setw是**一次性**的，下一行不生效；但std::setfill是**持久状态**，会影响后续所有输出 - 错误写法：
std::cout → 输出 <code>"***ab"（"b" 也被填充影响） - 正确做法：要么用
std::string拼好再输出，要么用 RAII 临时保存/恢复流状态（较重） - 更简单的规避方式：用
std::ostringstream构建单行，再整体输出
居中对齐这种需求，本质上是构造中间字符串的过程，强行塞进流操纵器反而增加心智负担和出错概率。
实际项目里，真正容易被忽略的是 Unicode 字符串：上述所有方案都按 char 计数，对 UTF-8 编码的中文、emoji 会把一个字算成多个字节，导致视觉宽度严重失准。真要支持宽字符对齐，得先做 Unicode 字形宽度计算（如用 ICU 库），那已是另一层复杂度了。
