命名返回值仅在多同类型返回、defer统一处理、主流路径为检查失败即退、返回值语义易歧义时提升可读性；单返回值命名纯属冗余。
命名返回值只在特定场景下真正提升可读性，不是所有函数都该用；滥用反而让逻辑更难追踪。
什么时候该给返回值命名
命名返回值本质是提前声明变量，并赋予语义。它只在以下情况有实际价值：
- 函数返回多个同类型值（比如两个
int），不命名根本分不清哪个是计数、哪个是状态码 - 需要在
defer中统一处理返回值（如关闭资源、包装错误） - 函数体以“检查-失败即退”为主流路径，裸
return能减少重复写return x, err - 返回值含义容易歧义（例如
func parse() (int, error)—— 这个int是 ID？长度？时间戳？）
反例：单返回值函数 func id() int 命名为 (result int)，纯属多此一举。
命名返回值的声明和裸 return 写法
在函数签名中直接写变量名+类型即可，Go 会自动初始化为零值：
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
func getUser(id int) (user *User, err error) {
if id <= 0 {
err = fmt.Errorf("invalid id: %d", id)
return // 裸 return，等价于 return nil, err
}
user = &User{ID: id, Name: "Alice"}
return // 等价于 return user, nil
}
注意：return 后不带参数才是“裸返回”，它依赖命名变量当前值；一旦用了裸 return，所有命名返回值都必须被显式赋值，否则可能返回未预期的零值。
命名返回值 + defer 的隐蔽陷阱
这是最容易踩坑的地方：defer 捕获的是命名返回值的地址，不是快照。
- 如果 defer 修改了
err，最终返回的就是修改后的值 - 如果函数体里先
err = nil，再defer func() { err = fmt.Errorf("wrapped") }()，调用方拿到的就是包装后的错误 - 但若函数中途
return后又在 defer 里改user，而user已被设为nil，那 defer 的赋值就覆盖了你本意的返回值
所以，只要用了命名返回值，就必须意识到 defer 不只是“收尾”，而是能真实篡改返回结果的机制。
性能与逃逸的隐性成本
命名返回值不是免费的：
- 编译器大概率将命名返回值分配到堆上（尤其当被取地址，如
&err），触发逃逸分析警告 - 结构体较大时，命名返回会多一次隐式零值初始化 + 后续赋值，而非命名返回可直接构造并返回
- 小函数（func add(a, b int) int）完全没必要命名，反而增加栈开销
真正该纠结命名的，是那些 IO 密集、错误路径多、返回值语义模糊的函数 —— 比如数据库查询、HTTP 客户端调用、配置解析这类边界清晰但易出错的场景。
