tabwriter必须显式用 分隔字段、每行末尾加 并调用Flush()才生效，否则输出乱码或为空；其按制表位逻辑对齐而非字符串长度，支持Unicode但需预处理中文宽度。
用 fmt.Printf 手动对齐字段容易出错，为什么不用 tabwriter
直接拼字符串或靠空格硬对齐，在列宽变化、含中文/emoji、字段含换行时会立刻崩。Go 标准库的 tabwriter 是专为这类场景设计的：它按制表位（tab）做逻辑对齐，再把 tab 转成空格，不依赖字符串长度估算。
关键点是：tabwriter.Writer 必须在写完所有行后调用 Flush()，否则输出为空；且每行末尾必须加
，否则对齐失效。
- 初始化时传入
minwidth（最小列宽）、tabwidth（一个 tab 展开为多少空格）、padding（列间额外空格） - 列内容里用
- 如果某列内容含
\t），否则破坏结构
处理多维数据（如 [][]interface{}）时如何安全写入 tabwriter
不能直接把 [][]interface{} 丢给 fmt.Fprint —— 它不会自动插入 。必须显式遍历每一行，把字段用 连接后再写入。
示例：对二维切片 data := [][]interface{}{{"Name", "Age", "City"}, {"Alice", 30, "Beijing"}, {"Bob", 25, "Shenzhen"}}：
立即学习“go语言免费学习笔记（深入）”；
tw := tabwriter.NewWriter(os.Stdout, 0, 0, 2, ' ', 0)
for _, row := range data {
for i, v := range row {
if i > 0 {
fmt.Fprint(tw, " ")
}
fmt.Fprint(tw, v)
}
fmt.Fprintln(tw) // 注意：必须用
换行
}
tw.Flush() // 必须调用，否则无输出
- 避免用
fmt.Fprintf(tw, "%v %v %v ", ...)—— 字段数不确定时易越界 - 若字段含
nil，fmt.Fprint输出<nil>，可提前用fmt.Sprintf("%v", v)统一转字符串再处理 - 数字列想右对齐？
tabwriter不支持对齐方向控制，得靠字段前补空格（不推荐），或改用第三方库如github.com/olekukonko/tablewriter
中文字符导致列错位，tabwriter 真的不支持 Unicode 吗
它支持，但默认按 byte 长度计算宽度，而中文占 3 字节（UTF-8），显示却只占 2 个等宽位置。结果就是中文列看起来“缩进过多”。
解决办法只有两个：
- 用
golang.org/x/text/width包的StringWidth手动计算显示宽度，然后动态调整tabwidth和minwidth（复杂且低效） - 更实际的做法：预处理字段，用空格补齐到统一显示宽度（例如用
strings.Repeat(" ", maxLen-len(str))），再喂给tabwriter—— 此时tabwriter只负责列间分隔，不对单列内部做宽度干预
后者更可控。注意：maxLen 必须按 rune 数（非 byte 数）计算，len([]rune(s)) 才是中文真实字符数。
需要表头加粗或颜色？tabwriter 做不到，但别急着换库
tabwriter 输出纯 ASCII，不带任何样式。如果只是终端显示，可以用 ANSI 转义序列包裹表头字段：
header := "[1m" + "Name" + "[0m" fmt.Fprint(tw, header, " ", "Age", " ", "City", " ")
- ANSI 序列会被
tabwriter当作普通字符处理，不影响 tab 对齐逻辑 - 但某些环境（如 CI 日志、重定向到文件）会显示乱码，需检测
os.Stdout.Fd()是否为终端，再决定是否启用颜色 - 真正需要跨平台样式（HTML/PDF 导出、Markdown 表格）时，才值得引入
tablewriter或gomarkdown类库
最常被忽略的是 Flush() 调用时机和
的强制要求——这两个点卡住过几乎所有第一次用 tabwriter 的人。
