tablewriter.newwriter() 必须传入 os.stdout 并调用 writetable() 或 render() 才能输出；表头用 setheader()、数据用 append()；中文需禁用 autoformatheaders 并启用 utf8；复用 writer 实例可提升性能。
tablewriter.NewWriter() 必须绑定 os.Stdout 才能立即看到输出
很多人调用 tablewriter.NewWriter() 后直接写数据，却没在终端看到表格——根本原因是没把 writer 绑定到标准输出或没调用 Render()。它默认不自动 flush，也不隐式关联终端。
- 必须显式传入
os.Stdout：tablewriter.NewWriter(os.Stdout) - 写完所有行后，一定要调用
WriteTable()或先Render()，否则缓冲区里的内容不会打印 - 如果想捕获输出做测试（比如写入
bytes.Buffer），可以传入那个 buffer，但生产命令行程序时别漏掉os.Stdout
表头和数据行要用 SetHeader() 和 Append() 分开设置
SetHeader() 只影响表头行，Append() 添加的是普通数据行；混用 Append() 传表头会导致列数错位、对齐失效，甚至 panic。
- 表头用
SetHeader([]string{"Name", "Age", "City"}) - 每条数据用
Append([]string{"Alice", "32", "Beijing"}) - 不要用
Append()去塞表头，也不要用SetHeader()塞多行数据 - 列数必须严格一致，否则
Render()会报panic: column count mismatch
中文字符导致列宽计算错误，得关掉 AutoFormatHeaders 和启用 UTF8
默认开启的 AutoFormatHeaders 会把中文当 ASCII 处理，算错宽度，结果表格严重错位。这不是 bug，是 tablewriter 对双字节字符的默认假设太保守。
- 加这一句：
table.SetAutoFormatHeaders(false) - 再加：
table.SetUTF8(true)，让宽度计算走 Unicode 字符计数而非字节计数 - 如果还歪，检查字体是否支持等宽中文（终端里用 Fira Code / Cascadia Code 等更稳）
- 别依赖
SetColumnAlignment()强行修——对齐逻辑跑在宽度计算之后，基础宽度错了，对齐也没用
性能敏感场景下避免反复 NewWriter + Render
每次新建 tablewriter.Writer 并调用 Render() 都有内存分配和字符串拼接开销。高频日志或 CLI 实时刷新时（比如 watch 模式），容易卡顿。
- 复用同一个
Writer实例：创建一次，后续用ClearRows()清空旧数据，再Append()新数据 - 禁用自动样式可提速：
table.SetAutoWrapText(false)、table.SetReflowDuringAutoWrap(false) - 如果只是简单两列对齐，考虑手写
fmt.Printf("%-20s %s\n", name, value)，比 tablewriter 轻量得多
tablewriter 的核心陷阱不在 API 多难，而在它默认行为和中文/终端/性能三者交叠时的“静默失准”——宽度算错不报错，列数不匹配才 panic，渲染不调用就不输出。这些点卡住过太多人一整个下午。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
