Go多返回值是错误处理和逻辑分层的基础设施，强制显式处理error、固定返回顺序、支持命名返回值与defer协作、多重赋值保障原子性、_标识符表达意图。
Go 的多返回值不是“语法糖”，而是整套错误处理和逻辑分层的基础设施。它直接决定了你写出来的函数是容易测试、容易组合，还是总得靠 panic 或全局状态来兜底。
为什么 Go 函数必须用 (T, error) 模式？
这不是风格选择，而是类型系统和编译器强制的协作契约：
-
error是接口类型，所有错误都必须显式暴露在函数签名里，调用方无法忽略 - 返回值顺序固定：业务结果在前，
error在最后，工具链（如go vet）能静态检查是否漏判err != nil - 不支持异常捕获，所以没有“隐式跳转”——所有分支路径都必须返回合法的 (T, error) 组合，逻辑更线性
命名返回值不是炫技，是控制变量生命周期的关键
当你写 func divide(a, b float64) (result float64, err error)，Go 会在函数入口自动把 result 初始化为 0.0、err 初始化为 nil。这意味着：
- 所有
return语句可以省略具体值（只写return），避免重复赋值出错 - 中间计算可直接写入
result，不用反复声明临时变量，尤其在多个 if/else 分支中优势明显 - 但要注意：命名返回值会“泄漏”到 defer 中——
defer func() { log.Println(result) }()打印的是最终值，不是 return 时的快照
多重赋值不是为了省行数，而是消除中间状态风险
比如你要交换 map 中两个 key 对应的 value：
立即学习“go语言免费学习笔记（深入）”；
data := map[string]int{"a": 1, "b": 2}
data["a"], data["b"] = data["b"], data["a"]
这行代码安全，因为 Go 先求右边两个 data[...] 的值，再原子写入左边。换成两行赋值就可能出错：
-
data["a"] = data["b"]→ 此时data["a"]已被覆盖，data["b"]原值丢失 - 再执行
data["b"] = data["a"]→ 两边都变成原data["b"]的值
这种“读-读-写-写”的原子性，在并发或复杂结构操作中是硬性保障，不是可选项。
空白标识符 _ 的真实用途不是“忽略”，是声明意图
写 _, ok := m[key] 不是为了少打一个变量名，而是告诉阅读者：“我只关心 key 是否存在，值本身无业务意义”。这影响三件事：
- 编译器不会报 “declared and not used” 错误
- 其他开发者一眼看懂这个 map 查找仅用于条件判断，不是数据提取
- 如果你误写成
v, _ := m[key]，说明你其实需要值，只是忘了用——这是个设计信号，值得回头检查逻辑
真正容易被忽略的，是命名返回值 + defer 的组合行为，以及多重赋值在 map/slice 赋值时的求值顺序。这两点不踩坑，多返回值才算真正用对了。
