strings.Repeat不能直接当填充函数用，因其仅机械重复字符串且不处理对齐逻辑，易因负数参数panic，且len(s)返回字节数而非字符数，中文等UTF-8字符会导致宽度计算错误。
strings.Repeat 为什么不能直接当填充函数用
strings.Repeat 的作用是重复拼接字符串，它不关心“对齐”这件事，只管机械复制。如果你拿它来凑长度（比如想把 "abc" 右对齐到 10 位），得自己算重复几次、补多少空格——容易漏掉边界情况。
常见错误现象：strings.Repeat(" ", 10-len(s)) + s 在 s 长度超过 10 时会生成负数参数，触发 panic：strings: negative Repeat count。
- 必须先做长度判断：
if len(s) >= width { return s } - 注意 Go 字符串是 UTF-8 编码，
len(s)返回字节数，不是字符数；含中文时会出错（如"你好"长度是 6） - 如果真要靠
strings.Repeat手动对齐，建议搭配utf8.RuneCountInString计算字符宽度
fmt.Sprintf 的 %*s 和 %Ns 填充行为差异
fmt.Sprintf 的占位符看似简单，但 %*s 和 %Ns 处理方式不同：前者把宽度作为运行时参数传入，后者在格式串里写死宽度值。两者都默认右对齐，加 - 才左对齐。
关键区别在于：当字符串实际长度 > 指定宽度时，%Ns 会截断（只取前 N 字节），而 %*s 不会截断，只是忽略宽度限制——这常被误认为“失效”。
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Sprintf("%10s", "hello")→" hello"（右对齐，补空格） -
fmt.Sprintf("%-10s", "hello")→"hello "（左对齐） -
fmt.Sprintf("%5s", "hello world")→"hello"（截断为前 5 字节） -
fmt.Sprintf("%*s", 5, "hello world")→"hello world"（不截断，宽度参数被忽略）
中文或 emoji 场景下 fmt 对齐失效的原因
fmt 的宽度单位是“字节”，不是“显示宽度”。一个汉字占 3 字节，一个 emoji（如 "?"）通常占 4 字节，但它们在终端里都只占 1 或 2 个字符位置。结果就是：fmt.Sprintf("%10s", "?a") 看起来远不止 10 列宽，甚至严重错位。
这不是 bug，而是设计如此——fmt 不做 Unicode 字形宽度计算。想真正按屏幕宽度对齐，得用第三方库（如 github.com/mattn/go-runewidth）先算出视觉宽度，再手动补空格。
- 避免用
fmt对齐含中文/emoji 的字符串，除非你明确只要字节对齐 - 若必须用，先用
runewidth.StringWidth(s)替代len(s)计算宽度 -
strings.Repeat(" ", max(0, targetWidth - runewidth.StringWidth(s)))才可靠
性能敏感场景该选哪个
纯字节对齐且不含 Unicode 扩展字符时，fmt.Sprintf("%*s", width, s) 比手拼 strings.Repeat 稍慢（因为格式解析开销），但代码更简洁；若已知宽度固定，fmt.Sprintf("%10s", s) 会被编译器优化，性能接近手动拼接。
真正影响性能的是反复调用和内存分配：每次 fmt.Sprintf 都新建字符串；strings.Repeat + + 在短字符串时也逃不过小对象分配。
- 高频调用时，考虑预分配缓存（如用
bytes.Buffer写入） - 宽度变化不大时，可提前生成常用空格字符串（如
spaces100 := strings.Repeat(" ", 100)），切片复用 - 不要为了“看起来快”而用
unsafe或反射绕过，Go 的字符串不可变性本身已是优化前提
对齐这事表面是补空格，背后是字节、字符、字形宽度三层概念的拉扯。没想清楚用哪一层对齐，就别急着选函数。
