fmt.printf适用于固定ascii字段的简单对齐，text/tabwriter则用于动态列数、含中文及需自动列宽计算的cli表格；前者易错位截断，后者必须调flush()且需处理中文宽度。
fmt.Printf 和 text/tabwriter 是最直接可用的两个方案，但适用场景完全不同：固定字段、ASCII 主导、结构简单 → 用 fmt.Printf；动态列数、含中文、需流式写入或自动列宽计算 → 必须用 text/tabwriter。
用 fmt.Printf 做静态列对齐（适合日志、简单报告）
它快、无依赖、一行搞定，但前提是字段长度可预估，且不混排中英文。
常见错误现象：中文显示错位、长字符串截断、列宽随内容变化而抖动。
-
%-12s表示左对齐、最小占 12 字符；%12d表示右对齐整数；宽度设小了会挤，设大了空隙难看 - 中文字符在终端通常占 2 列，但
fmt按字节计（UTF-8 下“你好”是 6 字节），所以%-12s对“张三”实际只留 6 个英文位，右边多出 6 个空格，视觉上就偏右 - 如果某列内容超宽（比如路径太长），它不会自动换行或截断，而是直接撑开，破坏整体对齐
- 推荐仅用于纯 ASCII 场景，例如：
fmt.Printf("%-8s %-6d %-15s\n", "user", 1001, "active")
用 text/tabwriter 实现自动列宽对齐（CLI 表格首选）
它是标准库里唯一能边写边算列宽的工具，本质是“\t 驱动的列对齐过滤器”，不是打印机。
常见错误现象：输出为空、全是原始 \t、中文列右偏、最后一行消失。
- 必须调用
w.Flush()，否则所有内容都卡在缓冲区里 —— 这是最常踩的坑 - 每行末尾必须带
\n，tabwriter只把\n当作“提交这一行”的信号，没它就不渲染 - 初始化时第三个参数（
padding）别设为 0，建议至少设 1 或 2，否则列挨太近，尤其含中文时易粘连 - 中文对齐不准？不是 bug，是设计限制：
tabwriter默认按字节宽计，不识别 rune 显示宽度；临时缓解可调大tabWidth到 12 或 16，但更稳做法是先用golang.org/x/text/width归一化宽度再喂给它 - 别在字段里塞
\t或换行符，会直接破坏列结构；预处理时需转义或替换
为什么不用第三方 tablewriter？什么情况下该换
如果你需要边框、居中、颜色、列宽手动锁定、或中文 100% 对齐，text/tabwriter 就不够用了。
典型信号：用户反馈“表格看起来像乱码”“城市名和年龄挤在一起”“标题没加粗”。
-
github.com/olekukonko/tablewriter能自动识别中文宽度、支持SetColWidth()、SetAlignment()、SetBorder(false)等精细控制 - 但它不是标准库，要额外
go get，且 API 更重：必须先SetHeader()，再逐行Append([]string{})，不能直接fmt.Fprintln - 高频 CLI 工具（如
ls类命令）建议复用同一个tablewriter实例，避免反复初始化开销 - 注意：它默认开启表头自动格式化（
AutoFormatHeaders），中文标题可能被截断，需显式关掉：table.SetAutoFormatHeaders(false)
text/tabwriter 的 Flush() 容易忘，fmt.Printf 的宽度难估，tablewriter 的初始化参数多——选哪个，取决于你愿为“看起来整齐”付出多少维护成本。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
