padleft 和 padright 是 c# 中最直接安全的字符串补齐方式，但默认补空格、不处理 null 或负长度；需用 (str ?? "") 和 math.max(0, len) 防错，且注意 unicode 宽度与显示差异。
PadLeft 和 PadRight 是 C# 中最直接、最安全的字符串补齐方式，无需正则或手动拼接，但默认补空格，且不处理 null 或负长度 —— 这两点最容易出错。
PadLeft 和 PadRight 的基本用法与参数含义
这两个方法都属于 string 实例方法，签名一致：string PadLeft(int totalWidth, char paddingChar)（PadRight 同理）。totalWidth 指补齐后的总长度，不是补几个字符；如果原字符串已≥该长度，会原样返回，不会截断。
常见误区是传入负数或零：此时会抛出 ArgumentOutOfRangeException。另外，paddingChar 不能是 Unicode 代理对（如某些 emoji），否则运行时报 ArgumentException。
-
"123".PadLeft(5, '0')→"00123" -
"ab".PadRight(4, '*')→"ab**" -
"hello".PadLeft(3, 'x')→"hello"（不截断）
如何安全处理 null 字符串和动态长度
直接对 null 调用 PadLeft 会触发 NullReferenceException。不要用 ?.PadLeft() 后再判空，因为结果仍是 null —— 补齐逻辑就断了。
推荐用空合并操作符提前兜底：
"abc".PadLeft(6, '0') // 安全<br>"".PadLeft(6, '0') // → "000000"<br>(str ?? "").PadLeft(6, '0') // str 为 null 时也返回 "000000"
若长度需动态计算（如补齐到某列宽），注意先做非负校验：
- 用
Math.Max(0, targetLength)防止负值传入 - 避免从用户输入或配置直接读取
int后直传 —— 比如配置项写成"-2"就崩
PadLeft/PadRight 在格式化输出中的典型陷阱
控制台对齐、日志字段对齐、生成固定宽文本文件（如 EDI）时常用它们，但容易忽略编码与显示宽度差异。例如：
- 中文字符在多数等宽字体中占 2 个英文字符宽度，但
PadLeft只按char数计数，不是视觉宽度 - 使用
' '补齐时，在某些终端或 CSV 查看器里多个空格可能被合并显示 - 若目标是“右对齐数字”，优先用
ToString("D4")等数字格式化，而非PadLeft—— 前者自动处理负号位置，后者会把负号挤到最左再补
比如：(-5).ToString("D3") → "-05"，而 "-5".PadLeft(3, '0') → "-5"（不够长不补），"-5".PadLeft(4, '0') → "0-5"（负号被当普通字符）。
替代方案：什么时候不该用 PadLeft/PadRight
当需要按字节长度补齐（如协议包填充）、按 Unicode 字素簇（grapheme cluster）对齐（如带变音符号的字符）、或支持多字符填充（如用 "--" 循环补）时，PadLeft 和 PadRight 就力不从心了。
此时应自行实现或借助 StringBuilder：
- 多字符填充：先算循环次数，再用
string.Concat(Enumerable.Repeat(...)) - 字节长度：用
Encoding.UTF8.GetByteCount(str)判断，再补 - 安全的图元对齐：需用
StringInfo拆分字符串，再计数
这些场景下硬套 PadLeft 表面跑得通，实际在边界输入上会错位或崩溃。
