str_pad处理中文长度错误的根本原因是按字节而非字符计数；UTF-8下“你好”占6字节，str_pad("你好",4,"0")因原长已超目标字节数而直接返回原串，不填充。
str_pad 处理中文时长度计算错误的根源
根本原因是 str_pad 按字节计长，不是按字符。UTF-8 中一个中文占 3 字节，str_pad("你好", 4, "0") 看似要补到 4 字符，实际却按字节判断：原字符串字节数是 6，已超目标长度 4，直接返回原串，不填充。
这不是 bug，是设计使然——str_pad 原生不感知编码，只数 strlen 返回的字节数。
用 mb_str_pad 替代 str_pad 的实操要点
PHP 5.6+ 提供了真正支持 Unicode 的 mb_str_pad，它按字符数（codepoints）计算长度，对中文、emoji、日文等完全可靠。
-
mb_str_pad必须显式传入encoding参数，例如'UTF-8'；漏掉会 fallback 到内部编码，可能出错 - 填充字符（
pad_string）本身也按字符处理：用"0"补零没问题，但用"✅"或"你好"作填充时，函数会自动截断或循环拼接，以满足字符数要求 - 若环境未启用
mbstring扩展，调用mb_str_pad会报Fatal error: Uncaught Error: Call to undefined function mb_str_pad()
示例：mb_str_pad("你好", 6, "0", STR_PAD_LEFT, 'UTF-8') → "00你好"（补 2 个字符，不是 2 个字节）
立即学习“PHP免费学习笔记（深入）”；
没 mbstring 扩展时的临时 workaround
如果无法启用扩展（如某些共享主机），只能手动模拟字符级填充，但要注意性能和边界：
- 先用
mb_strlen($str, 'UTF-8')获取真实字符长度 - 计算差值：
$diff = max(0, $target_len - mb_strlen($str, 'UTF-8')) - 用
str_repeat()拼接填充字符，再根据pad_type组合：左侧补就str_repeat($pad_char, $diff) . $str，右侧反之 - 注意：若
$pad_string是多字符（如"#*"），需手动循环截取或重复，不能直接用str_repeat
这种写法绕过了 mb_str_pad 的自动对齐逻辑（如 STR_PAD_BOTH 的右偏规则），需要自己实现对齐策略。
容易被忽略的兼容性陷阱
即使用了 mb_str_pad，以下三点仍常导致“看似正常、实则翻车”：
- PHP-FPM 或 CLI 下的默认内部编码可能不是 UTF-8，
mb_internal_encoding()返回值未必可信，务必在调用前显式设mb_internal_encoding('UTF-8') - 数据库读出的字段若未声明
charset=utf8mb4，或 HTML 表单提交未带accept-charset="UTF-8"，传进来的字符串实际是 GBK 编码，mb_str_pad按 UTF-8 解析就会乱套 -
mb_str_pad不校验输入字符串是否合法 UTF-8；若混入损坏字节（如截断的中文），mb_strlen可能返回 false 或异常值，建议前置用mb_check_encoding($str, 'UTF-8')防御
真正稳定的做法不是只换一个函数，而是把 UTF-8 编码控制贯穿输入、处理、输出全链路。
