因为闭包捕获的是变量地址&i而非值，for循环复用同一内存地址，所有闭包共享该地址；待goroutine或defer执行时，循环早已结束，i已定格为终值（如3或len(s)-1）。
闭包捕获变量时，i 为什么总是输出终值？
不是“闭包没记住”，而是它记住了 &i——所有闭包共享同一个内存地址。for 循环复用变量 i 的栈空间，每次迭代只改写值，不新建地址。等 goroutine 或 defer 真正执行时，i 早已是循环结束后的终值（比如 3 或 len(s)-1）。
常见错误写法：for i := 0; i → 输出 <code>3 3 3。
- 修复方式一（推荐）：
i := i; go func() { fmt.Println(i) }()—— 在循环体内声明新绑定，编译器能识别这是独立变量 - 修复方式二（更清晰）：
go func(idx int) { fmt.Println(idx) }(i)—— 参数在go语句执行瞬间求值，语义明确 - 绝对避免：
go func(i int) { ... }(i)是语法错误；go func() { ... }(i)也不合法
defer 中闭包捕获 x 是否一定逃逸？
不一定，但风险极高。是否逃逸取决于 x 是否被“外部持有”：如果 defer func() { println(x) }() 中的 x 是小基础类型（如 int、string），且该闭包不返回、不传 goroutine、不赋给全局变量，编译器可能保其在栈上；但只要出现 &x，或闭包被注册后生命周期超出函数作用域（比如 defer 链未清空就返回），x 就必然逃逸。
-
defer func(v int) { fmt.Println(v) }(x)→v通常不逃逸，安全 -
defer func() { fmt.Println(&x) }()→&x强制x逃逸到堆 -
defer func() { fmt.Println(x) }()→ 即使x是int，也大概率逃逸，因 defer 函数可能在栈帧销毁后才执行
怎么验证闭包是否引发变量逃逸？
不能靠经验猜，必须用编译器反馈。单个 -m 不够，要加 -l 禁用内联，否则逃逸信息会出现在调用方而非定义处，误判率高。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
命令：go build -gcflags="-m -l" main.go
- 看到
moved to heap: x或x escapes to heap→ 确认逃逸 - 看到
can inline且无 heap 提示 → 大概率未逃逸 - 若函数被内联，逃逸信息会跑到调用 site，加
-l后才能准确定位到x定义行 - 配合
go tool compile -S main.go | grep "runtime\.newobject"可进一步确认是否真有堆分配
结构体字段被闭包捕获，为什么整个结构体都逃逸？
Go 当前不支持字段级逃逸分析。哪怕你只在闭包里读 s.Name，只要闭包引用了 s（比如 func() { println(s.Name) }()），整个 s 就会被抬到堆上——因为编译器无法证明其他字段不会被间接访问。
- 优化手段：拆解传参，比如
go func(name string, age int) { ... }(s.Name, s.Age) - 避免
go func() { use(s) }()这类粗粒度捕获，尤其当s包含大字段（如[]byte、map）时 - 注意：即使
s是值类型，只要被闭包捕获，逃逸判断逻辑不变 - 接口传递（如
fmt.Println(func(){})）会加剧逃逸，闭包本身 + 捕获变量双重堆分配
int 被闭包拖到堆上，看似无害，但在每请求都创建闭包的 HTTP handler 里，它会让 GC 频次上升、CPU cache miss 增加、P99 延迟可测性变差——问题不在单次分配，而在累积效应。 
