defer修改返回值的唯一入口是命名返回值。匿名返回值不可寻址，defer无法修改；命名返回值是栈上真实变量，defer可直接读写；指针操作仅影响局部变量，不改变返回值本身。
命名返回值才是 defer 修改返回值的唯一入口
Go 中 defer 能修改返回值，和指针完全无关。很多人误以为“传指针进去就能改返回值”，但实际根本不需要、也不支持这么做——函数返回值本身不是可取地址的变量（除非是命名返回值）。所谓“配合指针”，本质是混淆了局部变量、返回值变量和内存地址三者的边界。
关键事实只有一个：defer 能修改的，仅限于函数签名中声明的命名返回变量（如 func() (x int) 中的 x），因为它在栈上真实存在、可寻址；而匿名返回值（func() int）没有绑定变量，defer 连它的影子都碰不到。
试图用指针绕过这个限制，比如写 func() int { x := 42; p := &x; defer func() { *p = 99 }(); return x }，最终仍返回 42 —— 因为 return x 拷贝的是 x 当前值，*p = 99 改的是局部变量 x，不影响已确定的返回副本。
为什么 defer 里取 &x 是合法的，但对匿名返回值无效
当函数定义为 func() (x int) 时，x 是一个真实的栈上变量，&x 能拿到它的地址，defer 闭包可以安全读写它。但这和“指针传参”无关，而是语法层面赋予的可寻址性。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
func f() (x int) { defer func() { *(&x) = 100 }(); return 5 }→ 返回 100，可行但毫无必要 -
func f() int { x := 5; defer func() { *(&x) = 100 }(); return x }→ 仍返回 5，&x只是局部变量地址，不关联返回值 - 你无法对
return 42的字面量取地址：&42在 Go 中非法
所以“指针配合”是个误导性说法：真正起作用的是命名返回值的变量身份，不是它的地址是否可取。
多个 defer 修改同一命名返回值时，顺序和副作用必须手动控制
命名返回值被多个 defer 修改时，执行顺序是 LIFO（后注册先执行），但每个 defer 对该变量的写操作是直接生效的，没有中间快照。这意味着结果取决于注册顺序和逻辑叠加方式，容易出错。
-
defer func() { x *= 2 }()和defer func() { x += 1 }()注册顺序不同，最终值可能差 1 或翻倍 - 如果某个
defer里 panic，后续defer不再执行，x的最终值就卡在中途状态 - 不要依赖
defer链式修改返回值；显式赋值再return更清晰：x = compute(); log(x); return x
最易被忽略的一点：即使你在 defer 里启动 goroutine 并尝试异步写 x，那也是未定义行为——函数栈帧即将销毁，x 的内存可能已被复用。
真正需要“指针感”的场景：defer 中访问外部变量而非返回值
如果你确实要用指针，通常是为了让 defer 闭包能观察或修改函数外的状态，比如资源清理或日志记录：
-
errPtr := &err; defer func() { if *errPtr != nil { log.Println("failed:", *errPtr) } }()—— 这里指针只是传递引用，不用于影响返回值本身 -
res := &result; defer func() { *res = postProcess(*res) }()—— 前提是result就是命名返回变量result int，否则*res改的仍是局部副本
归根结底，defer 修改返回值的能力只来自命名返回值这个语法特性，不是靠指针技巧撑起来的。写代码时，先看函数签名有没有名字；没有，就别想改返回值——这是 Go 的确定性设计，不是限制，是约束下的清晰性保障。
