Go多返回值要求赋值数量严格匹配，必须用多个变量或_接收；error习惯性置于末位；命名返回参数可被defer修改；返回值存于调用方栈帧预留区域。
多返回值赋值必须数量严格匹配
Go 不允许用单个变量接收多个返回值，编译器会直接报错。比如 os.Open 返回 *os.File 和 error，写成 f := os.Open("x") 就会触发 multiple-value os.Open() in single-value context。
正确做法只有两种：
- 用两个变量完整接收：
f, err := os.Open("x") - 用
_显式丢弃某个值：_, err := os.Open("x")或f, _ := os.Open("x")
注意：_ 不是“忽略”，而是语义上声明“我确认不要这个值”，它不分配内存，但编译器仍会执行对应返回值的计算逻辑。
error 必须和业务值一起返回，且习惯性放在最后
这不是语法强制，但已是 Go 生态铁律。几乎所有标准库函数（如 http.Get、os.ReadFile、strconv.Atoi）都把 error 放在最后一个返回位置。调用方默认按 val, err := fn() 模式处理。
立即学习“go语言免费学习笔记（深入）”；
如果函数签名是 func parse() (int, string, error)，你却写成 s, i, err := parse()，那 s 实际是 int 类型、i 是 string——类型错位不会在声明时报错，而是在后续使用时才暴露，调试成本高。
常见踩坑点：
- 把多返回值直接传给只接受一个参数的函数，例如
fmt.Println(os.Open("x"))→ 编译失败 - 在 defer 中修改命名返回参数时，误以为
return已结束，其实命名变量仍可被 defer 覆盖
命名返回参数会影响 return 行为和 defer 可见性
当你写 func do() (v int, err error)，v 和 err 就成了函数作用域内的变量，初始化为零值。此时 return 等价于 return v, err，无需再写具体值。
但这带来一个关键副作用：defer 函数能访问并修改这些命名变量。例如：
<pre class="brush:php;toolbar:false;">func f() (err error) {
defer func() { err = fmt.Errorf("deferred") }()
return nil
}
最终返回的是 "deferred"，不是 <code>nil。因为 return nil 先把 err 设为 nil，然后 defer 执行并覆盖它。
这种行为不是 bug，是设计使然——命名返回参数本质是栈上预分配的局部变量，生命周期覆盖整个函数体，包括 defer 阶段。
底层实现靠调用方栈帧预留空间，不是寄存器搬运
Go 的多返回值不是靠 CPU 寄存器塞多个值实现的。编译器会在调用方栈帧中，紧挨着入参之后，提前划出一块连续内存区域，用于存放所有返回值。
函数执行到 return 时，只是把局部变量值依次拷贝进这块预留区域；调用返回后，调用方直接从自己栈上读取即可。
这个机制决定了几个事实：
- 返回值数量不受硬件限制，只受栈空间约束
- 跨平台一致性高，不用适配不同架构的寄存器规则
-
defer能安全修改命名返回值，因为它操作的就是同一块栈内存
真正容易被忽略的是：哪怕你用 _ 丢弃某个返回值，该值仍会被计算、仍会占用栈空间、仍可能触发副作用（比如 http.Get 仍会发起网络请求）。所以别以为写了 _, _ := something() 就等于没调用。
