tabwriter.Writer需显式Flush()才输出，\n仅作行终止符，中文错位因按字节计宽，应预处理宽度或调大minWidth/tabWidth。
为什么 text/tabwriter 输出不换行、不缩进、像乱码？
因为 tabwriter.Writer 不是直接写字符串的“格式化器”，而是个缓冲型写入器：它必须显式调用 Flush() 才会真正输出对齐后的结果，否则所有内容都卡在内部缓冲区里。常见错误是写完就结束，没 Flush()，看着像啥都没输出。
- 必须在所有
Write()或WriteString()后调用w.Flush()，否则无输出 -
WriteString("a\tb\tc\n")中的\n不触发换行对齐——tabwriter只认\t做列分隔，\n仅作行终止符，且必须存在才能完成一行的对齐计算 - 如果漏写
\n，最后一行不会被渲染，也不报错
如何设置列宽、对齐和填充字符？
tabwriter.NewWriter() 的后三个参数分别控制最小单元宽度、空格填充数、标志位，不是“总宽度”或“对齐方向开关”。它们共同决定每列实际占位逻辑：
- 第一个参数（
minWidth）：每列内容至少占多少字符，不足则补空格；设太小（如0）会导致列塌缩，尤其含中文时容易挤在一起 - 第二个参数（
tabWidth）：每个\t视为多少空格宽，影响列间基准间距；一般用8，但若内容含全角字符，建议调大到12或手动预处理宽度 - 第三个参数（
padding）：列内容右侧额外补多少空格；设1能让多行之间视觉更松散 - 标志位常用
tabwriter.AlignRight或tabwriter.TabIndent，但注意：它们只对单列生效，且需配合\t位置使用，不是全局样式
中文文本对齐错位怎么办？
tabwriter 默认按字节计宽，而中文 UTF-8 是 3 字节/字，导致列宽计算严重偏差。它不会自动识别 rune 宽度，所以纯靠参数调不彻底解决。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 最稳方案：用
golang.org/x/text/width预先计算字符串显示宽度，再用空格补齐到目标宽度，最后喂给tabwriter - 临时缓解：把
minWidth和tabWidth都翻倍（比如设成16），但治标不治本，混排中英文时仍可能偏移 - 别依赖
strings.Repeat(" ", n)补空格来“模拟”对齐——tabwriter会把那些空格当内容，再叠加自身填充，反而更乱
能用 fmt.Printf 替代吗？什么场景非用 tabwriter 不可？
能做简单对齐，但动态列数、运行时生成表头、需要统一缩进策略时，fmt.Printf 很快失控。比如生成 CLI 工具的响应表格，字段名和值都是 map 构建出来的。
立即学习“go语言免费学习笔记（深入）”；
-
fmt.Printf("%-20s %-10s\n", k, v)要求你提前知道最大长度，而tabwriter是边写边算，适合未知长度的数据流 -
tabwriter支持在写入过程中插入带不同对齐的列（比如数字右对齐、状态左对齐），只需在对应\t前加标志，fmt没这种灵活嵌套能力 - 性能上，
tabwriter多一层内存拷贝，但对几百行以内的终端输出几乎无感；真要高速日志写入，就别用它——它本就不是为高吞吐设计的
真正麻烦的是混合中文、emoji、ANSI 颜色码的场景：这些都会干扰宽度计算，而 tabwriter 完全不感知。这时候要么剥离控制字符再对齐，要么干脆放弃自动对齐，用固定列宽 + strings.Repeat 手动拼接——它不优雅，但有效。
