命名返回值能被defer修改，非命名返回值不能，因前者是函数栈上真实可寻址变量，后者仅为临时返回槽；return先赋值再执行defer，闭包捕获变量地址才可修改。
命名返回值能被 defer 修改，非命名返回值不能——这不是 bug，是 Go 编译器按规范做的确定性行为。
命名返回值 vs 非命名返回值：返回值变量是否“真实存在”
关键区别在于：命名返回值是函数作用域内的真实变量，而非命名返回值只是临时 slot。这直接决定 defer 能否影响最终返回值。
- 命名返回（如
func f() (x int)）：x在栈上分配，return只是把当前值“留在那里”，defer可读写x - 非命名返回（如
func f() int）：return x会立刻把x的值拷贝进返回 slot，后续修改x不影响该 slot - 指针/结构体等复合类型返回时，即使非命名，只要返回的是地址或可变引用，
defer仍可能间接影响返回内容（例如return &i后在defer中改*&i）
defer 参数在注册时求值：循环中闭包陷阱的根源
常见错误：for i := 0; i 输出全是 <code>3。不是 defer 延迟执行的问题，而是参数 i 在每轮 defer 语句执行时就被求值并拷贝了。
- 正确写法：用局部变量捕获当前值，
defer fmt.Println(i)→val := i; defer fmt.Println(val) - 或用匿名函数传参：
defer func(v int) { fmt.Println(v) }(i) - 注意：如果传的是指针（如
&i），那所有defer共享同一地址，最终读到的仍是循环结束后的值
panic 触发时 defer 仍执行：但 recover 必须在 defer 内直接调用
panic 不跳过已注册的 defer，这是 Go 的保证；但 recover() 生效有严格限制。
-
recover()只在defer函数内部、且尚未返回前调用才有效；写在普通函数里等于没写 - 多个
defer中只有第一个recover()能捕获 panic，后续recover()返回 nil - 如果
defer里再panic且未被recover，原 panic 被覆盖，程序崩溃
最易被忽略的点：返回值 slot 和命名变量不是一回事，而 defer 参数求值时机与函数调用时机也不等价——这两处不一致，是绝大多数 “defer 没生效” 问题的源头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
