go语言中range修改slice元素无效、defer闭包捕获变量引用、nil与空切片判别错误、goroutine泄漏是四大典型隐患，根源在于值拷贝、延迟执行时机与生命周期理解偏差。
Go 语言里很多“看起来能跑”的代码，其实埋着 runtime panic、数据静默丢失、goroutine 泄漏这些隐患。它们不报编译错误，测试也常覆盖不到，上线后才突然爆发。
range 循环中修改 slice 元素无效
结构体、数组这类值类型在 for _, v := range s 中被拷贝，改 v 不影响原 slice。
- 现象：循环里给
v.Field = x，结束后原 slice 完全没变 - 正确做法是用索引：
for i := range s { s[i].Field = x } - 如果必须取地址（比如传给函数），得在循环内声明新变量：
v := v; f(&v)，否则所有指针都指向最后一次迭代的内存位置 - 切片本身是引用类型，但 range 迭代的是元素副本，不是底层数组指针
defer + 闭包捕获变量时读到的是执行时的值
defer 注册的是函数值，但闭包捕获的是变量引用，不是快照。
- 常见错误：
i := 0; defer func() { println(i) }(); i = 1→ 输出1，不是0 - for 循环里写
defer fmt.Println(i)，结果全输出终值（如5 5 5） - 修复方式：显式传参，
defer func(n int) { println(n) }(i) - 别依赖
go vet提示——它只对部分场景告警，旧版本甚至不报
nil 切片和空切片行为不一致
var s []int 和 s := []int{} 底层结构不同：前者 data 指针为 nil，后者指向合法地址。
- JSON 反序列化
null得到 nil 切片，前端传[]得到非-nil 空切片，用s == nil判断会漏 case - 某些 Cgo 封装或底层库要求切片非 nil 才能取
&s[0]，nil 切片直接 panic - 统一用
len(s) == 0判空；初始化优先写s := make([]int, 0)，语义清晰且行为可控 - 真要区分 nil/空，用
reflect.ValueOf(s).IsNil()，但别放热路径
goroutine 启动后没绑定 context 或没回收
裸写 go f() 是高危操作，尤其在循环或 HTTP handler 中。
- HTTP 客户端没设
Timeout、DB 查询没带context.WithTimeout、channel 写入无接收方 → goroutine 永久阻塞 - 批量任务必须配
sync.WaitGroup，且wg.Done()要在 goroutine 内部调用，不能 defer 在外层 - 推荐模式：用带缓冲 channel 控制并发数，或 worker pool + context.WithCancel
- 静态检查工具（如
staticcheck）能发现部分泄漏模式，但无法覆盖所有逻辑分支
这些坑大多发生在「变量生命周期」「内存模型理解」「延迟执行时机」这三个交叉点上，而不是语法记不住。越早建立对值拷贝、引用传递、defer 执行栈、goroutine 生命周期的直觉，调试成本就越低。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
