zfill()仅对字符串左补零且不处理小数点或多余符号；%02d等旧式格式化只适用于整数；f-string的f'{n:02d}'是目前最稳妥的整数补零方式，兼顾类型与精度。
zfill() 只能补左端零，且只对字符串有效
zfill() 是字符串对象的方法，不是通用数值格式化工具。它会把原字符串转成左对齐、指定总宽度、不足位补 '0' 的新字符串，但前提是原字符串里不能有符号（除非是 '-' 开头）或小数点——一旦含 '.' 或多个 '-'，结果就容易出人意料。
常见错误现象：'12.5'.zfill(6) 得到 '0012.5'（看似正常），但 '-12'.zfill(5) 得到 '-0012'（负号占一位，零补在符号后），而 '-12.5'.zfill(6) 直接返回 '-12.5'（不补零，因为含小数点）。
- 只接受一个参数：
width，必须是非负整数 - 如果当前字符串长度 ≥
width，直接返回原串，不截断 - 对数字类型要先转
str()，比如42.zfill(3)会报错：AttributeError - 不处理进制、千分位、科学计数法等场景
%02d 这类旧式格式化只适用于整数，浮点数会报错
像 %02d 这种写法来自 Python 2 的旧式字符串格式化，现在虽仍可用，但只认整数。传入浮点数（哪怕值是 42.0）就会触发 TypeError: %d format: a number is required, not float。
使用场景有限：适合快速拼接整数 ID、序号、月份这类确定为整数的字段，比如日志前缀 '%04d-%02d-%02d' % (2024, 3, 5) → '2024-03-05'。
立即学习“Python免费学习笔记（深入）”；
-
%02d中的0表示用零填充，2是最小宽度 -
%05.2f看似类似，但它补的是小数点前的空格（非零），小数点后才固定两位；想让3.1415变成'03.14'，得拆开处理 - 遇到负数时：
'%03d' % -5→'-05'（符号优先，零补在中间），不是'-005' - Python 3.6+ 更推荐用
f'{n:02d}'替代，语义更清晰、类型检查更友好
f-string 的 :02d 和 :05.2f 才真正兼顾类型与精度
f'{n:02d}' 是目前最稳妥的整数补零方式，底层调用 __format__，支持 int、float（只要值是整数）、甚至自定义类（实现相应协议）。比 % 和 .format() 更快，也更易读。
关键差异在于：它明确区分“整数格式”和“浮点格式”，不会混淆类型语义。
-
f'{42:04d}'→'0042'；f'{-7:04d}'→'-007'（符号占位，零补剩余） -
f'{3.14159:05.2f}'→'03.14'（总宽 5，小数点后 2 位，不足左补零） -
f'{123.4:08.1f}'→'000123.4'（注意：小数点也算一位，总字符数=8） - 对字符串变量用
f'{s:>05}'是右对齐补空格，想补零得写f'{s:0>5}'（0>表示右对齐、零填充）
补零逻辑本质是字符串对齐，别在数值计算中混用
所有补零操作最终产出的都是字符串，不是数字。这意味着你不能拿 '0042' 去做加减乘除，也不能直接存进数据库的整数字段（会报类型错）。
容易踩的坑：有人用 str(n).zfill(4) 处理用户输入的 ID，结果前端传来 '0042'，后端又 .zfill(4) 一遍，变成 '000042'；或者把 f'{x:02d}' 的结果当成 int 传给 API，导致 400 错误。
- 补零只应在输出环节做（日志、文件名、UI 展示、固定长协议字段）
- 输入解析阶段，应先用
int()或float()转成数值，再校验范围，最后按需格式化 - 涉及二进制/十六进制补零（如
'101'.zfill(8)→'00000101'），记得确认原始字符串是否已去除了'0b'前缀
