闭包捕获变量地址而非值快照，因此后续修改会影响所有引用该变量的闭包；典型问题出现在 for 循环中，若直接在 goroutine 或回调中使用循环变量，所有闭包共享同一地址，导致最终输出相同值。
闭包捕获的是变量地址，不是值快照
Go 的闭包不会在定义时“拍下”外部变量的值，而是绑定到变量所在的内存地址。这意味着：只要那个变量后续被修改，所有引用它的闭包在执行时都会看到最新值。
典型现象：for i := 0; i 输出全是 <code>3；for _, v := range items { go func() { process(v) }() } 所有 goroutine 都处理最后一个 v。
根本原因不是“延迟求值”，而是循环变量 i 和 v 在整个循环中复用同一块栈内存——闭包拿到的是 &i 或 &v，不是 i 或 v 的副本。
- 不要指望
defer func() { ... }()或go func() { ... }()自动隔离每次迭代的值 - range 的索引和值变量行为一致，都复用；哪怕
v是结构体，闭包捕获的仍是其地址（值语义是假象） - 调试时可用
fmt.Printf("%p", &v)确认是否真的在复用地址
修复必须切断变量复用链
唯一可靠方式，是在每次迭代中创建一个**新绑定的新变量**，让闭包捕获这个独立变量的地址。
两种等效写法，推荐后者（语义更直白）：
-
val := v; go func() { process(val) }()—— 显式拷贝，作用域清晰，Go 编译器对这种短变量声明做了逃逸优化，性能无负担 -
go func(val string) { process(val) }(v)—— 传参式，v在go语句执行时立即求值并复制，闭包内val是独立参数，不依赖外部作用域
注意：func(v string) { ... }(v) 是立即执行函数（IIFE），不能用于注册回调（如 cron.AddFunc），因为后者要的是 func() 类型，不是调用结果。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
defer 中的闭包陷阱更隐蔽
defer 不改变闭包捕获规则，但它放大了变量生命周期问题：所有 defer 语句共享同一个函数作用域，且统一在函数返回前执行。
常见错误：
for i := 0; i → 全输出 <code>3-
var err error; defer log.Printf("err: %v", err)放在函数开头，但err后续才被赋值 → 日志总显示<nil></nil> -
defer func() { x = 2 }()配合命名返回值 → 修改了返回值，但逻辑难追踪，可读性差
关键点：defer 捕获的是变量绑定，不是快照；它看到的值取决于执行时刻该变量的实际内容，而非声明时刻。
闭包持有大对象会阻碍 GC 回收
闭包隐式持有所引用的所有外部变量。如果闭包被长期持有（比如注册为 HTTP handler、存入全局 map、或启动后台 goroutine），而它又无意中捕获了大对象（如 *http.Request、context.Context、大 []byte），那这块内存就无法被 GC 回收。
排查方法：
- 用
go tool pprof查看 heap，找那些存活时间异常长、且引用了大结构体的 goroutine - 检查闭包是否捕获了整块
struct，其实只需要其中一两个字段 → 提前提取：id := req.URL.Query().Get("id")，再传入闭包 - 避免在闭包中直接使用
req或ctx，除非你明确需要它们的完整生命周期
最易被忽略的是：你以为传的是值，其实传的是指针；你以为只用了字段，其实闭包绑定了整个 struct 实例。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
