在go语言for循环中直接将循环变量传入匿名函数会导致所有闭包共享同一变量实例，最终全部执行时都使用最后一次迭代的值；正确做法是每次迭代创建新变量副本。
在使用 cron 等调度库开发任务系统时，一个高频且隐蔽的 Bug 就是：所有定时任务实际执行时都表现出“最后一个任务”的行为——例如日志中反复打印最后读取的 job.Name 和 job.Interval，而完全忽略前面的任务配置。
根本原因在于 Go 的 for range 循环中，job 是单个变量的复用（而非每次迭代新建），其内存地址始终不变。当匿名函数 func() { DistributeJob(job) } 被注册到 cron 时，它捕获的是对这个可变变量 job 的引用，而非其当前值的快照。等到 cron 实际触发执行时，循环早已结束，job 已被赋值为切片末尾的最后一个元素——因此所有闭包都输出相同结果。
✅ 正确写法：显式创建循环局部副本
for _, job := range config.Jobs {
realJob := job // ← 关键：每轮迭代创建独立变量，地址唯一
c.AddFunc("@every "+realJob.Interval, func() {
DistributeJob(realJob) // 此处闭包捕获的是 realJob 的稳定副本
})
log.Println("Job " + realJob.Name + " has been scheduled!")
}realJob := job 触发了结构体值拷贝（假设 Job 是值类型），为每次迭代生成一个独立变量，确保每个匿名函数绑定的是各自专属的 job 副本。
⚠️ 常见错误写法辨析
- ❌ func(job Job) { ... }(job)：语法非法——func(...) {...}(args) 是立即执行函数（IIFE），但 cron.AddFunc 要求传入 func() 类型，而非调用后的返回值。
- ❌ 直接使用 &job 取地址：若 job 是结构体，&job 始终指向同一内存地址，问题依旧；若后续循环修改 job，还可能引发数据竞争。
- ❌ 在 goroutine 中 go func() { ... }()：虽场景不同，但共享变量问题同源，需同样用 realJob := job 隔离。
? 验证技巧：打印变量地址辅助调试
可在循环中加入诊断日志：
立即学习“go语言免费学习笔记（深入）”；
log.Printf("job addr: %p, realJob addr: %p", &job, &realJob)你会观察到 &job 地址恒定不变，而 &realJob 每次均不同——直观印证变量隔离的有效性。
? 总结
Go 中闭包捕获的是变量本身，而非其瞬时值。在 for range 中安全传递循环变量，唯一可靠方式是：在循环体内显式声明新变量并赋值。这一原则不仅适用于 cron 调度，也适用于 http.HandleFunc、time.AfterFunc、事件回调等所有需延迟执行的闭包场景。养成 copyVar := loopVar 的习惯，可彻底规避此类“幽灵复用”问题。
