error必须放在最后一个返回位置，这是Go生态的硬性契约，所有标准库和主流包均遵循该约定，调用方默认用val, err := fn()接收，乱序会导致类型错位、解构混乱及工具链警告。
error 必须放在最后一个返回位置
这不是风格偏好，是 Go 生态的硬性契约。所有标准库（os.Open、strconv.Atoi、json.Unmarshal）和主流包都把 error 放在末尾，调用方默认用 val, err := fn() 模式接收。如果写成 err, val := fn()，变量类型会错位——err 实际得到的是第一个返回值的类型，后续使用直接报 cannot use ... as type error。
更隐蔽的问题是解构混乱：a, err, b := f() 语义模糊，既破坏可读性，也违背工具链预期（比如 go vet 会警告）。编译器不拦你，但下游代码大概率崩。
- 命名返回参数时也要守序：
func parse() (data string, err error)才能保证return "ok"自动填充err = nil - 若函数逻辑上需同时返回“存在性”和“值”，推荐
val, ok, err三元组，其中ok表示业务存在（如 map 查找），err表示操作失败（如 I/O 错误）
显式接收或丢弃，不能跳过 error
_, err := os.Open("x") 合法，f := os.Open("x") 编译失败——Go 不允许隐式截断多返回值。你无法只取前一个值，也不能把它当单值传给 fmt.Println 等函数。
常见错误是用 _ 忽略 error：表面上通过了编译，实际掩盖了关键失败路径。比如 _, _ := json.Marshal(v)，序列化失败时无感知，后续可能 panic 或写入脏数据。
- 真正该忽略
error的场景极少：仅限于明确知道不会出错的操作（如硬编码字符串转time.Time且已验证格式） - 若真要忽略，必须加注释说明理由，例如：
// safe: config is static and validated at init - 测试中可用
require.NoError(t, err)替代_，既跳过又留痕
避免过度设计：什么时候该用结构体替代多返回值
不是所有多返回值都优雅。当返回项超过 3 个、类型相似（如 int, int, int, error）、或存在逻辑分组（如分页结果含 items, total, page, perPage, err），就该考虑封装为结构体。
结构体能带字段名，消除顺序依赖；支持方法扩展（如 IsEmpty()）；便于未来加字段而不破坏接口；还能用指针返回避免拷贝开销。
- 反例：
func getUser() (name string, age int, city string, country string, err error) - 正例：
type User struct { Name, City, Country string; Age int }+func getUser() (User, error) - 注意：结构体字段名不影响类型推导，但能大幅降低调用方理解成本
命名返回参数 + defer 的陷阱
命名返回参数（如 func do() (v int, err error)）让 return 变得简洁，但和 defer 结合时容易误判执行时机。
典型坑：return nil 先赋值给命名参数 err，再执行 defer 函数——后者能修改这个变量。结果是函数看似返回 nil，实则返回 defer 中新设的 error。
- 这不是 bug，是设计行为，但极易被当成“黑魔法”
- 除非明确需要延迟覆盖（如统一日志/清理），否则避免在 defer 中修改命名返回参数
- 调试时用
fmt.Printf("err=%v\n", err)在 defer 前后打点，比猜更可靠
