函数返回非nil error时主值应视为无效，正确做法是失败时返回nil主值和错误，成功时返回值和nil错误，如os.Open等标准库函数所示，确保调用方能安全依赖err判断结果有效性。
在Go语言中，函数返回 nil 值但非 nil error 是一种常见但容易引发运行时 panic 的设计问题。虽然 Go 没有强制要求错误处理的统一模式，但开发者应遵循清晰、一致的约定来避免调用方误用返回值。
明确 error 为 nil 才能使用返回值
最核心的原则是：只有当 error == nil 时，返回的主值才应该被信任和使用。如果函数执行失败（即返回了 error），即使主值不是 nil，也不应保证其有效性。
例如，以下代码存在隐患：
func GetData() (*Data, error) {if failed {
return &Data{}, fmt.Errorf("load failed") // 错误：即使出错也返回非nil指针
}
// 正常逻辑...
return result, nil
}
调用者可能误以为只要有值就可以用，从而忽略 error 判断。正确做法是：出错时返回 nil 主值：
立即学习“go语言免费学习笔记（深入）”；
return nil, fmt.Errorf("load failed")统一返回语义，增强可读性
保持所有路径下的返回逻辑一致，有助于调用方形成稳定预期。建议采用如下模式：
- 成功时：返回有效值 + nil error
- 失败时：返回 nil（或零值）+ 非 nil error
这样调用代码可以安全地写成：
data, err := GetData()
if err != nil {
handleError(err)
return
}
// 此处 data 可安全使用
这种结构已成为 Go 社区的事实标准，出现在标准库如 os.Open、json.Unmarshal 等函数中。
特殊情况的处理建议
某些场景下，函数可能部分成功，比如解析多个配置项时个别失败。此时仍需谨慎设计：
- 若整体视为失败操作，应返回 nil 结果 + error
- 若允许部分结果可用，可通过返回结构体包含 warning 或 partial 标志位，而不是依赖 nil/非nil 来表达状态
- 避免让调用方“猜”返回值是否有效
例如：
type Result struct {Data []Item
Warnings []string
}
func Process() (*Result, error)
这种方式将“错误程度”显式化，既保持 error 表示严重故障，又允许携带部分有效信息。
基本上就这些。只要坚持“error 非 nil 时主值无效”的原则，就能大幅提升接口的安全性和可维护性。不复杂但容易忽略。
