Go多返回值是设计核心而非语法糖，强制显式接收或丢弃、error必居末位、类型由返回顺序决定、命名返回参数受defer影响。
Go 语言的多返回值不是语法糖，是设计核心——它直接绑定错误处理、资源管理、解构赋值这些日常操作，用错方式会导致 panic、内存泄漏或静默失败。
函数声明里写多个返回类型，调用时必须显式接收或丢弃
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") - 常见错误：把多返回值当单值传给只接受一个参数的函数，比如
fmt.Println(os.Open("x"))—— 这会编译失败 - 注意：
_是占位符，不是“忽略”，它不分配内存，但语义上表示“我确认不要这个值”
error 必须和业务值一起返回，且习惯性放在最后
这不是约定俗成，是 Go 生态的契约。几乎所有标准库和主流包都把 error 放在最后一个返回位置，调用方默认用 val, err := fn() 模式处理。
- 如果你写
func parse() (err error, data string)，下游代码大概率会写成data, err := parse()，结果data得到的是error值，err反而得到string—— 类型不匹配还可能编译通过（如果都是接口或空接口） - 性能影响：
error是接口类型，返回它本身没有额外开销，但若你在函数里构造了带堆分配的 error（比如fmt.Errorf），那每次出错都会触发一次小内存分配 - 别为了“看起来整洁”把 error 提前，破坏一致性比多写一行更伤协作
用多重赋值解构时，变量类型由右值决定，不是声明顺序
Go 的 := 是类型推导，不是“左边定义类型”。比如 a, b := foo()，a 和 b 的类型完全取决于 foo() 声明的返回类型顺序。
- 陷阱：如果
foo()返回(int, string)，但你不小心写成s, i := foo()，那s就是int类型，i是string—— 编译器不会警告，后续使用会报类型错误 - 调试技巧：遇到“cannot use x (type y) as type z”这类错误，先检查多返回值接收顺序是否和函数签名一致
- 结构体字段名不影响推导，只有返回类型的顺序和具体类型起作用
defer + 多返回值要注意命名返回参数的“延迟可见性”
当你用命名返回参数（比如 func do() (v int, err error)），defer 中可以访问并修改这些变量——但这不是魔法，是编译器生成的隐式局部变量。
- 典型坑：
func f() (err error) { defer func(){ err = errors.New("deferred") }(); return nil }，最终返回的是"deferred"，不是nil—— 因为return nil先把err设为nil，再执行defer把它覆盖 - 这不是 bug，是设计行为。但容易被当成“return 后还能改返回值”的黑魔法，其实只是命名返回参数在函数栈帧里一直可写
- 建议：除非真需要（比如统一错误包装），否则少用命名返回参数，优先用普通变量 + 显式
return v, err，逻辑更直白，也不易被defer意外干扰
多返回值本身很简单，难的是它和 error 处理、defer 执行时机、变量作用域这些机制咬合在一起——漏掉其中一环，问题就藏得深，表现还可能是运行时 panic 而非编译错误。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
