spew 是 Go 中能深度展开变量结构的调试工具，支持递归展示指针、未导出字段、循环引用等，而 fmt.Printf 无法做到；其 Dump/Sdump/Fdump 分别输出到 stderr、返回字符串、写入任意 io.Writer；测试中需禁用指针地址、开启键排序、限制深度以保证稳定性；应避免修改全局 spew.Config，优先使用 ConfigState 局部配置。
spew 是 Go 后端调试中真正能“看到变量里面长什么样”的工具，不是简单输出地址或空结构体。它默认就递归展开所有指针、切片、map、嵌套 struct，连未导出字段和循环引用都能安全处理——这点 fmt.Printf 完全做不到。
什么时候必须用 spew.Dump 而不是 fmt.Printf
当你遇到以下任一情况，fmt.Printf("%v", v) 就已经失效：
- 打印的是
*[]*User，输出只有(*[]*main.User)(0xc000012340)，看不到里面每个User的字段值 - 结构体里有未导出字段（如
name string），fmt直接忽略，spew照打不误 - 两个 struct 互相持有对方指针，
fmt会卡死或 panic，spew自动标记为<shown></shown>并继续输出 - 需要在测试断言失败时快速看清
got和want的深层差异，而不是一行地址对比
spew.Dump、spew.Sdump、spew.Fdump 怎么选
三者核心逻辑一致，区别只在输出目标和返回值：
-
spew.Dump(v1, v2)：直接写到os.Stderr，适合开发期快速看一眼，不用管返回值 -
spew.Sdump(v1, v2)：返回string，适合拼进日志、测试失败信息、HTTP 响应体（比如调试接口返回前 dump 出来） -
spew.Fdump(w, v1, v2)：写入任意io.Writer，比如文件、bytes.Buffer、甚至 HTTP response writer
注意：spew.Dump 默认输出到 stderr，不是 stdout；如果用在 CLI 工具里想重定向，记得用 spew.Fdump(os.Stdout, ...)。
避免测试环境暴露指针地址和不稳定排序
单元测试里用 spew 打印期望值（want）或实际值（got）时，指针地址和 map 键顺序会随每次运行变化，导致 diff 失效或难以比对：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 禁用指针地址：
spew.ConfigState{DisablePointerAddresses: true} - 强制 map 键排序：
SortKeys: true（否则 map 输出顺序非确定） - 限制深度防爆炸：
MaxDepth: 5（尤其面对未知第三方结构体时） - 测试中推荐封装一个稳定输出函数：
func TestDump(v interface{}) string { return spew.ConfigState{ DisablePointerAddresses: true, SortKeys: true, MaxDepth: 5, }.Sdump(v) }
生产环境慎用全局 spew.Config 修改
spew.Config 是包级全局变量，修改它会影响整个进程所有 spew 调用：
- 不要在 init() 或 main() 开头写
spew.Config.DisableMethods = true，除非你确认所有地方都不需要调用String()或Error() - 想局部控制？一定用
spew.ConfigState{...}.Dump(...)或.Sdump(...)，别碰全局 Config - 特别注意
DisableMethods：设为true会跳过Stringer和error接口，可能让你错过关键错误信息或自定义格式化逻辑
最常被忽略的点是：很多人以为 spew 只是“更好看的 fmt”，其实它默认行为更激进——自动调用方法、展开未导出字段、跟踪指针链。这些能力在调试时是优势，在日志或 API 响应中若不加约束，反而会泄露敏感内存布局或触发副作用。
