error 必须放在多返回值函数末尾，因工具链和生态约定要求；命名返回值使 defer 可修改 err，但会覆盖主逻辑错误；defer 不捕获错误，忽略 Close 等错误将埋雷。
error 必须是多返回值函数的最后一个参数，这不是语法强制，但跳过它会导致编译失败、linter 报错、协作混乱——所有标准库和主流包都按此约定设计。
为什么 error 一定要放在返回值末尾
Go 编译器不检查 error 位置，但工具链（go vet、errcheck）和人脑阅读都默认它在最后。一旦写成 func() (error, int)：
- 调用方写
result, err := f()会直接报错：multiple-value f() in single-value context - 即使强行用
err, result := f()，后续if err != nil判断后，result可能是零值且未初始化，逻辑出错 -
os.Open、io.ReadFull、json.Unmarshal等全部标准函数都遵循(T, error)模式，混用等于主动脱离生态
命名返回值 + defer 修改 err 的真实行为
命名返回值（如 func() (data []byte, err error)）让 defer 能读写该变量，但它的作用不是“拦截错误”，而是“覆盖即将返回的值”：
-
return语句执行时，先给命名变量赋值，再触发defer -
defer中对命名err的赋值，确实会改变最终返回值，但仅限于该变量本身 - 多个
defer按后进先出顺序执行，后注册的会覆盖前一个对同一命名变量的修改 - 如果函数里有
return fmt.Errorf("early")，这个值会被defer里的赋值覆盖——这常被误认为“defer 拦截了错误”，其实是你手动改了它
defer 中调用可能返回 error 的函数必须显式处理
defer f.Close() 看似安全，但 Close() 本身可能返回非 nil 的 error（比如网络中断导致的 net.OpError），而这个错误会被彻底丢弃：
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 不要写
defer f.Close()后就不管了；更不能写_, _ = f.Close() - 正确做法是包一层匿名函数并检查：
defer func() { if e := f.Close(); e != nil { /* 记录或合并到外层 err */ } }() - 若函数有命名
err，可在 defer 中赋值：err = e，但要注意是否真想用Close()的错误覆盖主逻辑错误 - HTTP handler 中
resp.Body.Close()、数据库事务tx.Rollback()都属此类，忽略即埋雷
别用 defer 替代错误检查，它不传播也不捕获
defer 不是 try/catch，它不感知 error 值，也不影响控制流。常见误用：
- 写
defer fmt.Println(err)—— 此时err是函数开头的零值，不是return时的值 - 以为
defer能“捕获”panic—— 它只是保证执行，真正捕获得靠recover()，且必须在defer内部调用 - 在循环中写
for _, f := range files { defer f.Close() }—— 所有defer共享最后一个f，实际只关了最后一个文件
最易被忽略的一点：命名返回值 + defer 的组合，在函数分支复杂时会让错误来源变得模糊——你得翻完整个函数才能确认最终 err 是哪一行写的、被哪个 defer 改过。这种“隐式赋值”比显式 return err 更难 debug。
