defer在return赋值后、函数栈销毁前执行，命名返回值可被修改而匿名返回值不可；参数在defer语句执行时即求值；多个defer按lifo顺序执行；有真实性能开销，慎用于高频路径。
defer在return之后、函数栈销毁前执行
defer不是“函数退出后”才跑，而是在return语句完成赋值、但函数栈帧还没弹出的精确时间点执行。这个时机决定了命名返回值能被修改，而匿名返回值不能——比如func() (x int) { x = 1; defer func(){x++}(); return }返回2，但func() int { x := 1; defer func(){x++}(); return x }仍返回1。
常见错误是误以为defer在return“之后”才开始执行，结果发现变量值没变。实际流程是：return → 写返回值到栈 → 执行所有defer → 清理栈帧 → 返回调用方。中间这段“写完值但没离开”的窗口，就是defer唯一能触达命名返回值的机会。
参数在defer语句执行时就完成求值
这是最常踩的坑：写defer fmt.Println(i)，循环里i从0变到9，最终全输出9。因为i的值在执行到那行defer时就被拷贝固定了，不是执行时再读。
- 值类型（
int、string）直接复制一份 - 指针或引用类型（
*int、[]byte、map）拷贝的是地址，后续改内容会影响defer执行结果 - 想捕获当前值？显式传参：
defer func(n int) { fmt.Println(n) }(i) - 想捕获运行时最新值？用闭包：
defer func() { fmt.Println(i) }()
多个defer按LIFO顺序执行，和代码位置无关
defer f1.Close()和defer f2.Close()谁先注册谁后执行？不看缩进、不看上下文，只看执行顺序：最后那个defer最先执行。这决定了资源释放是否安全——比如打开文件A、再打开文件B，必须先关B再关A，否则可能触发use of closed network connection。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
典型反例：mu.Lock(); defer mu.Unlock()配对没问题，但如果中间又嵌套锁mu2.Lock(); defer mu2.Unlock()，就得确保mu2.Unlock()在mu.Unlock()之前注册，否则解锁顺序错乱。
defer有真实CPU和内存开销，高频路径要警惕
每次defer都会分配一个runtime._defer结构体，链入goroutine的defer链表。Go 1.21基准测试显示：空函数+defer比纯return慢3–5倍；每秒百万次调用的热路径上，GC压力会明显升高。
尤其注意循环内写defer：for i := range s { defer cleanup(i) }会累积N个待执行延迟调用，不仅拖慢性能，还可能OOM。简单清理动作（如清空局部map、重置slice）优先用显式代码，别硬套defer。
真正需要defer的场景很明确：配对资源（文件/锁/连接）、panic恢复（recover必须在defer里）、耗时统计——其他时候，先问自己一句：它真需要延迟到函数末尾才执行吗？
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
