sprintf适用于纯数字前导零不丢失场景，str_pad仅适合字符串且易因类型转换丢零；sprintf支持小数补零，str_pad不支持；str_pad需注意参数含义及空值处理。
数字补零最稳妥、最常用的是 sprintf，str_pad 适合字符串场景但容易在数字前导零被意外截断时翻车。
什么时候该用 sprintf 而不是 str_pad
当你处理的是纯数字（比如订单号、ID、时间戳片段），且必须确保前导零不丢失、类型不隐式转换时，sprintf 是首选。它按格式化规则输出字符串，不会把 "00123" 当成数字再转回来——而 str_pad 如果传入的是整数 123，它会先转成字符串 "123" 再补，这没问题；但如果你从数据库读出的是带前导零的字符串，又误用了 intval() 再传给 str_pad，零就没了。
-
sprintf('%05d', 42)→"00042"（安全，强制按整型格式补零） -
str_pad(42, 5, '0', STR_PAD_LEFT)→"00042"（表面一样，但输入若为"0042"就可能被转成42） - 涉及小数补零？
sprintf('%.3f', 1.5)→"1.500"，str_pad做不了这个
str_pad 的三个参数怎么选才不踩坑
str_pad 看似简单，但第二、三、四个参数配合不当，很容易补错位或补错字符。关键点是：它只管“字符串长度”，不管语义。
- 第二个参数是目标总长度，不是补几个零。比如
str_pad('7', 3, '0', STR_PAD_LEFT)补两位，得"007"；但str_pad('107', 3, '0', STR_PAD_LEFT)不补，因为原长已够 - 第三个参数只能是单字符，想用
"00"补？不行，会截成"0" - 第四个参数必须用常量：
STR_PAD_LEFT（左补）、STR_PAD_RIGHT（右补）、STR_PAD_BOTH（两边补），写字符串如"LEFT"会静默失败 - 如果变量可能为空或 null，先
(string)$var转下，否则str_pad(null, 3, '0')返回"00"（PHP 8+ 是"00"，旧版行为更混乱）
整数转固定位字符串时，sprintf 的格式符差异
sprintf 的格式符决定补零逻辑和类型边界，选错会导致截断或科学计数法输出。
立即学习“PHP免费学习笔记（深入）”；
-
%05d：整数，不足5位左补0，超长照常输出（sprintf('%05d', 123456)→"123456"） -
%05s：当字符串处理，sprintf('%05s', '42')→"00042"，但遇到数字字符串含空格或符号会异常 -
%05.0f：浮点数格式，但强制不显小数点，适合大整数防科学计数（sprintf('%010.0f', 123)→"0000000123"） - 注意：
%d对超大整数（如 > PHP_INT_MAX）可能溢出变负数或截断，此时应改用%s配合str_pad或直接字符串操作
为什么有时候补零后还是显示不对
常见不是函数用错了，而是数据源头或上下文干扰了结果。
- MySQL 查询里用了
INT字段存编号，即使设了ZEROFILL，PHPmysqli默认仍返回整数，前导零丢失——得用mysql_fetch_assoc()+ 显式sprintf补 - JSON 输出时，
json_encode(['id' => '00123'])没问题，但若写成['id' => 00123]，PHP 把00123当八进制字面量，实际是83 - HTML 表单提交的数字，浏览器可能自动去零，后端收到的就是
123，别指望前端 JS 补零能替代后端校验
补零看着简单，真正卡住人的往往是数字怎么来的、在哪一层被转过型、要不要考虑国际化或存储精度——这些地方比函数选哪个更值得盯紧。
