裸返回仅在命名返回值且全部显式命名时可用，否则易致零值误返或 defer 副作用；适用场景极窄，限于简单封装函数，复杂逻辑须显式 return。
裸返回 return 什么时候能用、什么时候会坑人
裸返回不是语法错误，但它是 Go 中少数几个「写起来省事，读起来费劲，改起来要命」的特性。它只在命名返回值（named return parameters）存在时才生效，且必须和函数签名完全对齐——少一个变量、类型不匹配、顺序错乱，编译器立刻报错。
常见错误现象：return 后不带任何值却编译失败；或看似正常，但某个命名返回值被意外覆盖为零值（比如 err 被漏赋值，结果返回 nil）。
- 仅当所有返回值都在函数签名中显式命名时才可裸用，例如
func foo() (a int, b string, err error) - 裸
return会按签名顺序自动填充当前作用域中同名变量的值，不会做任何推导或默认赋值 - 如果中途提前
return，但某个命名变量还没被赋值，它就取该类型的零值——这常是隐蔽 bug 的来源
命名返回值 vs 普通返回：参数列表里多写几个名字到底值不值得
命名返回值本质是函数体内的局部变量，声明即初始化为零值。它带来的唯一好处是减少重复写变量名，代价是增加理解成本和维护风险。
使用场景很窄：只适合逻辑简单、返回值少（≤2）、且每个返回值生命周期清晰的函数，比如标准库中常见的 io.Read 或 net.Dial 风格函数。
立即学习“go语言免费学习笔记（深入）”；
- 命名返回值会让函数签名变长，影响可读性，尤其当类型本身就很复杂时（如
func parse() (map[string][]int, error)） - 无法在裸
return前对命名变量做条件赋值而不显式写出——比如想在某个分支里跳过err赋值，裸返回就会带出零值 - Go vet 会对未使用的命名返回值发出警告，但很多人直接忽略，导致变量名过时、语义漂移
defer + 裸返回的组合最容易掉进的陷阱
这是最典型的翻车现场：defer 在函数返回前执行，但它捕获的是命名返回值的**地址**，而非当时值。如果 defer 修改了命名变量，裸 return 就会把修改后的值带出去——而你可能根本没意识到那个 defer 在动返回值。
示例：
func f() (x int) {
defer func() { x++ }()
return 5
}
结果是 6，不是 5。因为 defer 改了 x 的值，裸 return 返回的是最终值。
- 只要用了命名返回值 +
defer修改它，就必须意识到裸return是“延迟求值”的 - 想避免副作用？要么不用命名返回值，要么在
defer里用匿名函数捕获当时的值（defer func(val int) { ... }(x)） - 标准库几乎不用这种组合，就是因为它太容易误判执行顺序
团队协作中要不要禁用裸返回
不需要全局禁止，但要限制使用边界。裸返回的价值只存在于「极简封装」场景，比如包装一个标准接口调用并透传错误，此时命名返回值确实能少写一两个词。
真正复杂点的业务逻辑，裸返回只会让 reviewer 多花三秒确认每个命名变量是否都被正确赋值过——而这三秒累积起来就是时间黑洞。
- CI 可加
golint或自定义检查：禁止在非 trivial 函数中使用裸return - 命名返回值的变量名必须准确反映用途（
err就该是 error，不能叫e），否则裸返回等于埋雷 - 一旦函数开始加分支、加循环、加多个
if err != nil判断，立刻退回到显式return val, err
裸返回不是语法糖，是责任转移——把「确保每个返回值都显式设置」的责任，从代码行转移到了程序员脑子里。脑子容易忘，代码不会。
