Go语言陷阱避坑全攻略

本文深入剖析Go语言开发中两个高频且隐蔽的陷阱：一是nil切片与空切片在底层实现和语义上的关键差异，揭示直接用`s == nil`判空导致逻辑错误、前后端不一致等真实问题，并强调统一使用`len(s) == 0`的安全实践；二是goroutine泄漏的典型成因——未绑定context、缺乏生命周期管控的裸起协程，尤其在循环中极易引发资源耗尽。文章以底层原理为锚点，给出可立即落地的避坑方案，助你写出更健壮、可维护的Go代码。

Go 中 nil 切片和空切片行为不一致，别直接用 == nil 判断

很多人以为 var s []int 和 s = []int{} 是一回事，其实它们底层结构不同：前者 data 指针为 nil，后者 data 指向一个真实地址（哪怕长度为 0）。这会导致 s == nil 返回 false，但 len(s) == 0 为 true。

实际场景中，比如函数返回切片时没初始化就直接 return，调用方用 if s == nil 做空判断会漏掉空切片；而 JSON 反序列化时，null 字段默认转成 nil 切片，但前端传 [] 会得到非 nil 空切片 —— 两边逻辑对不上。

• 统一用 len(s) == 0 判断是否为空，而不是 s == nil
• 如果必须区分 nil 和空，用 reflect.ValueOf(s).IsNil()（仅调试/特殊逻辑，别放热路径）
• 初始化切片优先写 s := make([]int, 0) 而非 var s []int，语义更明确、行为更可控

goroutine 泄漏：别在循环里直接起 goroutine 且不控制生命周期

常见写法：for _, v := range items { go process(v) }。问题在于：如果 process 阻塞、panic 或没做超时，这些 goroutine 就永远卡住，内存和 goroutine 数持续上涨，直到 OOM。

典型触发点是 HTTP 客户端没设 Timeout、数据库查询没上下文取消、或 channel 写入没接收方。

• 所有 goroutine 必须绑定 context.Context，并在入口处用 select { case 响应取消
• 批量任务用 sync.WaitGroup + defer wg.Done()，主协程调用 wg.Wait() 等待完成（注意别在 goroutine 里 defer，会延迟释放）
• 避免在 for 循环里直接 go f()，改用 worker pool 模式或带缓冲的 channel 控制并发数

struct 字段首字母小写导致 JSON 序列化丢失字段

Go 的 JSON 包只导出首字母大写的字段。写 type User struct { name string }，json.Marshal 出来永远是 {}，连 omitempty 都没机会生效。

这个坑常出现在快速原型阶段：本地 struct 设计完直接扔给 HTTP handler，结果 API 返回空对象，日志也看不出错 —— 因为 marshal 过程没报错，只是静默跳过。

• 字段名必须首字母大写，如 Name string，再通过 json:"name" tag 控制 key 名
• 别依赖 IDE 自动首字母大写，检查 go vet 输出（它会提示 “field … not exported”）
• 如果真要支持私有字段序列化，得自己实现 MarshalJSON 方法，但通常没必要，暴露字段语义更清晰

defer 在循环中闭包捕获变量值错误

写 for i := 0; i ，输出是 3 3 3，不是 2 1 0。因为 defer 延迟执行时，i 已经循环结束，所有 defer 共享同一个变量实例。

这个问题在资源清理（如文件 close、锁 unlock）中尤其危险：多个 defer 实际操作的是同一个句柄或 mutex。

• 在 defer 前用局部变量捕获当前值：for i := 0; i
• 或者把 defer 放进立即执行函数：for i := 0; i
• 更推荐方式：把需要 defer 的逻辑封装成函数，参数传值而非引用，自然隔离作用域

最麻烦的不是语法记不住，而是这些坑往往不报错、不 panic，只在特定负载或数据下才暴露 —— 比如某个接口压测时 goroutine 数缓慢上涨，查半天才发现 context 漏传了；或者上线后某天前端突然收不到字段，回溯才发现 struct 字段小写了两周。

今天关于《Go语言陷阱避坑全攻略》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！