sprintf() 支持左对齐（%-10s）和右对齐（%10s），比 str_pad() 更适合多字段动态对齐；中文对齐需注意 mb_strlen 与终端渲染差异，性能敏感场景应预编译格式字符串。
用 sprintf() 做左/右对齐最直接
php 没有内置的“字符串对齐”函数，但 sprintf() 的格式化占位符天然支持宽度和对齐控制。关键不是“怎么输出”，而是“怎么写格式字符串”。%-10s 表示左对齐、最小宽 10；%10s（无减号）是右对齐。
常见错误：把 str_pad() 当万能解，但它只补空格、不处理变量插值，拼接多字段时容易错位。
-
sprintf("%-12s | %8d | %6.2f", $name, $age, $score)—— 三列对齐，中间用竖线分隔 - 数字对齐慎用
%d直接占位：负数会挤占宽度，改用%6d或%+6d显式留符号位 - 中文字符在终端里常显示为全角宽度，
sprintf()按字节算宽，会导致实际视觉错位——这不是 bug，是编码与渲染层不匹配
str_pad() 只适合单字符串补空格
它只管“一个字符串补到指定长度”，不管上下文或变量类型。适合生成固定宽日志前缀、ID 编码补零这类简单场景，不适合动态字段对齐。
典型翻车现场：用 str_pad($name, 10) . str_pad($age, 5) 拼接，结果年龄数字一多就顶破列宽，因为没预留分隔符空间。
立即学习“PHP免费学习笔记（深入）”；
- 补空格方向用
STR_PAD_LEFT/STR_PAD_RIGHT/STR_PAD_BOTH，别硬写数字 0/1/2 - 第二个参数是**总长度**，不是补几个空格。传
strlen($s) + 2不如直接算好目标宽再传 - 第三个参数默认是空格，但传
" "或"."会破坏对齐逻辑，除非你真要可视化填充效果
终端输出对齐失效？先看 mb_strlen() 和编码
用 sprintf() 或 str_pad() 对中文对不齐，大概率是因为 PHP 把 UTF-8 中文当 3 字节算，而终端（尤其是 windows cmd）按字符显示。结果就是“明明设了 10 宽，看起来只占 4 格”。
这不是函数问题，是 strlen() 和终端渲染的 gap。别急着换库，先确认真实需求：是给人看的日志？还是给机器读的 CSV？
- 给人看的终端输出，优先用
mb_strimwidth($s, 0, $width, '', 'UTF-8')截断 +str_pad()补，比硬套sprintf()更稳 - 导出 CSV 或 HTML 表格，对齐交给
<table> 或列宽样式，PHP 层只管转义，别自己 pad <li>检查脚本文件编码是否真是 UTF-8（无 bom），ide 和终端编码设置是否一致，很多“对不齐”其实是编码污染</li> <h3>性能敏感场景别在循环里用 <code>sprintf()格式化本身不重，但每次调用都要解析格式字符串、做类型推断。如果在高频日志循环里写
sprintf("[%s] %s", date('H:i:s'), $msg)，比直接字符串拼接慢 2–3 倍。真正卡点不在函数名，而在重复编译格式模板。PHP 8.1+ 可用
Stringable+ 预编译，但多数情况没必要。- 日志类里把格式字符串抽成常量，比如
private const LOG_FMT = "[%s] %s";，然后sprintf(self::LOG_FMT, ...) - 纯拼接且无类型转换需求时，
"[$time] $msg"比sprintf()快，也更易读 - 需要对齐的批量数据（如导出报表），先用
array_map()统一格式化，再implode("n")，别边循环边 echo
对齐的本质是“控制输出宽度”，不是“调用某个高级函数”。中文、emoji、终端差异、性能边界——这些细节堆起来，才是实际写的时候最花时间的地方。
- 日志类里把格式字符串抽成常量，比如