Go 代码的健壮性不靠运气，而靠对边界、并发、输入和错误的显式处理。没有防御式设计的 Go 程序，在真实流量或异常输入下大概率会 panic、数据竞争或静默失败。
validate.Struct() 为什么总返回 nil 而不是错误？
常见现象是 validate.Struct() 没报错，但业务逻辑仍出错——根本原因是结构体字段没导出（首字母小写），validator 库无法反射访问。
- 必须确保待验证字段是导出字段（如
Username string，而非username string） - 嵌套结构体也要导出，且需在 tag 中显式声明
validate:"required"，否则默认跳过 - validator 不校验 nil 指针字段；若字段类型是
*string，需额外加nonniltag - 自定义验证函数注册后，tag 名必须与注册名完全一致，大小写敏感
defer + recover 不能捕获 goroutine panic
recover() 只对当前 goroutine 有效。主 goroutine 的 defer 对子 goroutine 的 panic 完全无感，这是最常被忽略的健壮性盲区。
- 不要在启动 goroutine 的函数里放
defer/recover试图兜底子任务 - 每个可能 panic 的 goroutine 内部必须独立包裹
func() { defer recover(); ... }() - 更推荐用
errgroup.Group统一管理多个 goroutine，并通过Wait()收集错误，而非依赖 panic 恢复 - 日志中出现
panic: runtime error: invalid memory address却没被 recover，基本可断定是 goroutine 未防护
context.WithTimeout() 忘记调用 cancel() 的后果
漏掉 cancel() 不仅导致 context 泄露，还会让关联的 timer、goroutine、HTTP 连接长期驻留，最终拖垮服务内存和 fd 数。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
cancel()必须在函数退出前调用，哪怕提前 return；用defer cancel()是最稳妥方式 - 不要把
cancel()传给其他 goroutine 异步调用——一旦原 goroutine 结束，cancel函数变量即失效 - HTTP handler 中使用
context.WithTimeout(r.Context(), ...)后，务必defer cancel()，否则每个请求都泄露一个 timer - 用
go tool trace或pprof/goroutine可快速发现堆积的 timer 和阻塞的 goroutine
json.Unmarshal() 对空值和零值的静默处理
json.Unmarshal() 把缺失字段设为零值（0、""、nil），且不报错。这导致“字段没传”和“字段传了但值为零”无法区分，业务逻辑极易误判。
- 需要区分是否提供字段时，改用指针类型（如
*string），缺失时为nil，再配合omitemptytag 控制序列化 - 避免直接解到 struct，先解到
map[string]any，手动检查 key 是否存在 - 第三方库如
github.com/mitchellh/mapstructure提供DecodeHook可定制零值判定逻辑 - 对关键字段（如
user_id、amount），应在 Unmarshal 后立即做非零/非空校验，不依赖 JSON 解析结果本身
健壮性的最大陷阱，是把“没崩”当成“正确”。Go 的静态类型和明确错误返回降低了出错概率，但也容易让人低估运行时边界——比如 context 泄露要压测数小时才暴露，data race 在低并发下永远不触发。真正的防御，是每处外部交互都预设它会失败、超时、为空、越界。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
