str_pad按字节而非字符计算长度，中文易出错；填充方向需用STR_PAD_LEFT等常量；禁止空填充字符串；不截断原串，超长时直接返回原值。
str_pad 用不对，补出来的全是空格或乱码
PHP 的 str_pad 看似简单，但实际用时经常补错长度、补错方向、甚至中文变乱码。根本原因不是函数有问题，而是没搞清它按「字节」而非「字符」计算长度，且默认填充字符是空格（ASCII 32）。
常见错误现象：str_pad("你好", 10, "0") 结果是 "你好000000"（只补了 6 个 0），你以为该补 8 个？其实 "你好" 占 6 字节（UTF-8 下每个汉字 3 字节），str_pad 按字节算：10 - 6 = 4 → 只补 4 个 "0"。
- 要按「字符数」补全，得先用
mb_strlen($str, 'UTF-8')获取真实字符长度，再手动计算需补字节数（不推荐） - 更稳妥的做法：统一转成单字节编码（如 GBK）再 pad，但会丢 UTF-8 兼容性；或改用
mb_str_pad（PHP 8.3+ 才有） - 若只是处理英文/数字 ID 类字符串，直接用
str_pad最安全
第三个参数填空字符串或 null 就会报 Warning
str_pad 的第三个参数 $pad_string 不允许为空字符串或 null，否则触发 Warning: str_pad(): Padding string cannot be empty。
- 传空字符串
""→ 报错 - 传
null或未传 → 实际等价于" "（一个空格），但 PHP 会静默转，不建议依赖 - 想用零填充？写清楚
"0"，别写0（数字会被转成 ASCII 48 对应的字符，结果一样，但语义不清） - 想用 Unicode 符号（如 ⚪）？确保整个脚本文件是 UTF-8 编码，且 Web 输出头也声明 UTF-8，否则可能显示为
补左边还是右边？别靠记忆，看第二个参数取值
str_pad 的第四个参数 $pad_type 控制方向，只有三个合法值：STR_PAD_RIGHT（默认）、STR_PAD_LEFT、STR_PAD_BOTH。它不是布尔值，也不是字符串 "left"/"right" —— 写错就回退到默认右补。
立即学习“PHP免费学习笔记（深入）”；
-
STR_PAD_RIGHT：原字符串在左，填充在右（最常用，比如日志对齐） -
STR_PAD_LEFT：原字符串在右，填充在左（比如补零生成固定位数订单号） -
STR_PAD_BOTH：两边平分填充；若无法均分，多出的一个字符加在右边（例如str_pad("a", 5, "x", STR_PAD_BOTH)→"xxaxx"） - 别写
"left"或0代替STR_PAD_LEFT，PHP 不认，会当无效参数忽略
性能和兼容性：小数据无所谓，大循环里慎用
单次 str_pad 开销极小，但如果你在 foreach 里对上万条记录逐条补零生成编号，又用了 UTF-8 中文 + 自定义填充符，那实际是在反复做字节计算和内存复制。
- PHP 7.4+ 对
str_pad做过优化，但底层仍是 C memcpy，不涉及正则或编码转换时很快 - 真正慢的是你用
mb_strlen+str_repeat+substr自己模拟str_pad—— 这种组合比原生str_pad慢 3–5 倍 - PHP 8.3 引入了
mb_str_pad，支持多字节安全填充，但目前还没普及，线上环境别急着切
最常被忽略的一点：str_pad 不会截断原字符串。如果目标长度小于原串字节长度，它直接返回原串 —— 这不是 bug，是设计如此。需要截断得自己加 substr。
