PadLeft没生效主因是参数理解错误和未处理输入脏数据：默认用空格填充而非'0'，首参为总长非补零数，须Trim()防空格干扰，null需判空，数字优先用ToString("Dn")。
PadLeft 为什么没生效？检查参数顺序和填充字符
最常见的问题是把 PadLeft 当成“自动补零函数”，却忽略了它有两个必需参数：总长度和填充字符。如果只传一个参数，比如 str.PadLeft(5)，它默认用空格填充，不是零——所以看起来“没补零”。
- 必须显式传入
'0'作为第二个参数：str.PadLeft(5, '0') - 第一个参数是「最终字符串长度」，不是「要补几个零」；如果原字符串已比目标长度长，
PadLeft直接返回原串，不截断也不报错 - 数字转字符串再 PadLeft 前，建议先用
ToString()明确格式，避免隐式转换引入空格或符号干扰（比如负数）
处理数字时，别绕弯子：用 ToString("Dn") 更稳
如果你只是想把整数转成固定位数的零填充字符串（比如 42 → "00042"），直接调 ToString("D5") 比 PadLeft 更简洁、更少出错。
-
D格式说明符专用于十进制整数的零填充，"D5"表示至少 5 位，不足左补零 - 它自动处理负号：-42.ToString("D5") 得到 "-0042"，而
"-42".PadLeft(5, '0')会变成 "0-42"——逻辑完全不同 - 不适用于非数字字符串（如 "abc"），这时才轮到
PadLeft出场
PadLeft 在路径或 ID 拼接中容易漏掉 Trim
从数据库或用户输入拿到的字符串常带空格或不可见字符，直接 PadLeft 会导致填充位置错乱，比如 " 123 ".PadLeft(6, '0') 结果是 " 123 "（长度已够），根本没补。
- 关键操作：补零前先
Trim()，尤其是处理外部输入时：input.Trim().PadLeft(8, '0') - 如果原始值可能是
null，PadLeft会抛NullReferenceException，得提前判空或用空合并：(input ?? "").Trim().PadLeft(8, '0') - 注意编码问题：某些全角空格（如\u3000）不会被
Trim()清掉，必要时加.Replace("\u3000", "")
性能差异小，但大量循环里别在每次迭代里重复计算长度
单次 PadLeft 开销可忽略，但在高频场景（如日志流水号生成、批量导出）中，反复写 value.ToString().PadLeft(10, '0') 会产生多余临时字符串。
- 如果目标长度固定且已知，优先用插值或
ToString("D10")，它们底层更轻量 - 若必须用
PadLeft且长度动态（比如按某配置变量），把长度值存为局部变量，别写成PadLeft(config.MaxIdLength, '0')这种每次都读属性的写法 - 字符串驻留（interning）对
PadLeft无帮助，别试图手动String.Intern()优化
实际用的时候，最常卡住人的不是语法，而是忘了 Trim() 和误判了 PadLeft 第一个参数的含义——它不是“补几个”，而是“最终多长”。
