Go语言里的多返回值用起来很顺手，尤其是把一个业务结果和一个 error 同时返回，能让错误处理路径非常直白。标准库中的 os.Open、io.Copy、strconv.Atoi 都是典型例子。但顺手的前提是调用方始终清楚每个返回值代表什么。一旦函数签名经过几次迭代，比如有人调整了返回值顺序、插入了一个新值，或者把两个同类型的结果对调，原先依赖位置解构的调用代码就可能在没有明显告警的情况下读到错误数据。本文会从这个位置消费的隐患说起，再给出几种能显著降低维护成本的改进方式。
位置消费：多返回值的基础约束
Go 的函数返回值在调用侧没有类似命名参数那样的机制，调用方只能按照函数声明中的顺序把返回值逐个绑定到变量上。也就是说，一个返回 (string, int, error) 的函数，调用时写成 host, port, err := parse()，这里的 host 永远对应第一个返回值的语义，port 对应第二个。这个过程中没有字段名参与，完全依赖位置约定。
这种设计在简单场景中非常高效，因为编译器可以快速完成解构，调用方也不需要多余的对象构造。但问题在于，位置约定并不会被编译器当成一种语义契约来检查。编译器只能检查类型是否匹配，无法知道第二个返回值到底应该表示端口还是连接数。如果两个返回值类型相同，位置调换之后代码依然可以编译通过，但业务含义已经发生了偏移。
func fetchStats() (int, int, error) {
total := 120
failed := 3
return total, failed, nil
}
func main() {
total, failed, err := fetchStats()
if err != nil {
// 处理错误
}
fmt.Println(total, failed)
}
上面这段代码看起来没有任何问题。但如果后续修改了 fetchStats 的返回顺序，比如先返回失败数再返回总数，而两个值又都是 int 类型，那么 total 变量实际接收到的是失败数，failed 变量接收到的是总数。这种错误不会在编译期暴露，只能在运行期通过数据异常才能被发现。
跳过返回值与同类型顺序调换的典型陷阱
Go 语言允许用下划线跳过不关心的返回值，这是标准库中非常常见的写法。例如只关心 io.Copy 返回的错误时，调用方通常会写成 _, err := io.Copy(dst, src)。这种写法本身没有问题，问题在于一旦函数返回值数量或顺序发生变化，所有包含下划线的调用点都需要重新确认。
更隐蔽的情况发生在两个业务返回值类型相同时。假设有一个解析目标的函数，最初返回主机名和协议名：
func parseTarget(raw string) (string, string, error) {
return "ipipp.com", "https", nil
}
// 调用方只想拿协议，跳过 host
_, scheme, err := parseTarget("ipipp.com")
if err != nil {
return
}
fmt.Println(scheme)
如果某次重构把返回顺序调整为 (string, string, error) 但语义变成先返回协议再返回主机名，调用方的 _, scheme, err 依然可以编译通过，但 scheme 变量实际拿到的是主机名。由于两个返回值类型完全一致，编译器不会给出任何提示。这类陷阱在代码审查中很容易被忽略，尤其是当调用点分散在多个包中时。
还有一种情况是多返回值中错误值被跳过。比如 _, _, port := parse() 直接把第三个返回值赋给 port，但第三个位置如果原本是 error，类型不匹配会触发编译错误。可一旦函数返回的三个值类型兼容，例如都是 int 或都是 string，错误值被忽略的问题就不会被编译器拦截。因此团队需要约定：error 必须显式处理，不能通过下划线跳过。
用结构体封装替代裸多返回值
对于返回两个以上业务值的函数，引入一个小结构体往往能从根本上消除位置依赖。结构体字段自带名字，调用方通过字段名访问结果，顺序调整不会影响既有代码。下面是把前面的统计函数改造成结构体返回的示例：
type Stats struct {
Total int
Failed int
}
func fetchStats() (Stats, error) {
return Stats{Total: 120, Failed: 3}, nil
}
func main() {
stats, err := fetchStats()
if err != nil {
// 处理错误
}
fmt.Println(stats.Total, stats.Failed)
}
这种方式有多个好处。第一，调用方看到字段名就能理解含义，不需要回到函数定义处确认位置关系。第二，后续要给返回值增加新字段时，只要新字段有默认零值，旧的调用代码无需修改。第三，函数签名中的返回值数量减少为两个，更符合 Go 社区对 (T, error) 形式的偏爱。
并不是所有多返回值都要结构体化。如果一个函数只返回一个业务结果和一个错误，比如 (*User, error)，继续使用裸返回值是合理的。结构体封装更适合返回同一实体下的多个属性，例如主机和端口、总数和失败数、最小值和最大值。这些属性天然属于一个概念，用结构体表达更加清晰。
命名返回值与辅助函数的中间态方案
Go 支持在函数签名中为返回值命名，这种写法能提升函数内部的可读性，也能通过裸 return 明确返回内容。例如：
func fetchStats() (total int, failed int, err error) {
total = 120
failed = 3
return
}
命名返回值在函数内部确实有用，变量名可以直接表达语义，也可以减少局部变量声明。但调用侧依然无法按照名称来绑定返回值，调用方还是必须按顺序书写变量。因此命名返回值只能缓解内部维护问题，不能防止外部调用点陷入位置陷阱。它更像是一个文档化手段，而不是接口安全机制。
如果某些历史 API 已经对外暴露了裸多返回值，并且暂时不能调整签名，可以考虑在包内增加一个辅助函数来承担结构化返回。旧函数继续保留兼容，新代码统一走辅助函数。这样既不会破坏现有调用方，也能逐步引导团队远离位置敏感写法。辅助函数内部负责调用旧函数并组装结构体，集中处理顺序变化带来的影响。
工程实践与性能取舍
很多开发者担心把返回值包装成结构体会增加堆分配，从而影响性能。实际上，Go 编译器对小型结构体的返回有良好的栈分配优化，很多情况下结构体并不会逃逸到堆上。是否真正产生额外分配，需要通过 go test -bench 和 -gcflags=-m 来确认，而不是凭感觉下结论。在绝大多数业务代码中，可维护性提升带来的收益远大于纳秒级的性能差异。
团队可以形成一条简单规则：如果函数返回两个以上业务值，并且这些值属于同一概念，就优先定义结构体；如果返回的是一个结果和一个错误，就沿用 (T, error) 惯例；如果返回两个同类型业务值且语义容易混淆，必须使用结构体或给返回值命名并补充文档。代码审查时重点关注出现多个下划线跳过的调用点，检查是否有错误值被忽略。
多返回值是 Go 语言的一大便利特性，但便利不应该建立在脆弱的位置约定上。通过结构化返回、明确错误处理约定以及必要的辅助函数，可以把多返回值的高效性与代码长期可维护性更好地结合起来。下次写函数签名时，不妨先想一想：未来的维护者能否一眼看出第三个返回值的含义？如果答案不确定，也许就是该引入结构体的时候了。