Go强制返回error是为了让调用者显式处理失败，核心是“错误是值”和“失败须显式处理”；忽略err易致panic，%w保留错误链便于诊断，自定义错误应聚焦可观测性，多步错误宜用平铺结构快速失败。
Go函数返回 error 不是为了“凑数”，而是语言设计强制你直面失败——**每个可能出错的操作，都必须让调用者明确知道它可能失败，并决定怎么应对**。
这背后没有魔法，只有两条铁律：错误是值、失败要显式处理。下面说清楚怎么做、为什么必须这样、以及你十有八九踩过的坑。
为什么不能忽略 err？——空白标识符 _ 是静默崩溃的起点
Go 编译器不拦你写 file, _ := os.Open("missing.txt")，但工具链（如 go vet）会警告，运行时更会直接 panic：nil 的 *os.File 调用 Read 或 Close 就崩。
- 常见错误现象：服务偶发 panic，日志里只有一行
panic: runtime error: invalid memory address，找不到源头 - 真实场景：文件不存在、权限不足、网络超时、JSON 解析失败——这些都不是“异常”，而是正常业务流中的分支
- 正确做法：只要函数签名含
error，就必须检查；哪怕只是记录后返回，也不能丢弃 - 唯一可忽略
err的合理场景：在defer中调用file.Close()，且你确认资源已成功打开（此时应加注释说明）
fmt.Errorf 用 %w 还是 %v？——决定你能否用 errors.Is 定位原始错误
包装错误不是为了拼字符串好看，而是为了保留错误链。用错动词，就等于把诊断线索一把火烧了。
- 用
%w：原始错误被包裹，可用errors.Is(err, os.ErrNotExist)判断，也可用errors.As(&dbErr)提取底层类型 - 用
%v：只剩字符串描述，errors.Is永远返回false，日志里看到"failed to read config: file does not exist"却没法自动分流告警 - 典型误用：
return fmt.Errorf("config load failed: %v", err)→ 改成return fmt.Errorf("config load failed: %w", err) - 兼容性影响：Go 1.13+ 才支持
%w和errors.Is；低于此版本需降级为字符串匹配（不推荐）
自定义错误类型该不该实现 error 接口？——不是“能不能”，而是“要不要带上下文”
标准 errors.New 和 fmt.Errorf 够用，但当你要区分“用户输错密码”和“数据库连不上”，或需要透传错误码、请求 ID、时间戳时，就得自己造轮子。
- 基础原则：结构体字段应聚焦可观测性，比如
Code int、TraceID string、Original error - 不要重写
Error()去打印堆栈（那是debug.PrintStack()的事），而要返回对运维/前端友好的提示 - 示例中常见错误：把整个
http.Request塞进错误结构体（内存泄漏风险）、在Error()里做耗时操作（影响错误传播性能） - 轻量替代：多数场景用
fmt.Errorf("auth failed [code=%d]: %w", ErrInvalidToken, err)已足够清晰
多个步骤都可能返回 error，怎么写才不嵌套成意大利面？——用“快速失败 + 平铺结构”代替 if-else 套娃
Go 社区共识：错误处理逻辑应该左对齐，主流程保持视觉通透。嵌套 else 不仅难读，还容易漏掉某一层的 err 检查。
- 反模式：
if err == nil { if valid { ... } else { ... } } else { ... }—— 缩进深、新增校验难、review 时容易跳过错误分支 - 正解：每个步骤后立刻
if err != nil { return ... }，后续逻辑自然落在顶层缩进 - 性能影响：无额外开销；相比异常机制，Go 的值传递反而更快（基准测试显示错误路径快 2–3 倍）
- 实操提醒：别在循环里反复
return err却忘了收集全部错误；真要聚合，用 Go 1.20+ 的errors.Join
真正难的从来不是写 if err != nil，而是在接口边界处想清楚：这个错误是该由我吞掉重试，还是该暴露给上层决策？是业务规则拒绝（比如余额不足），还是系统失联（比如 Redis timeout）？——后者决定了你的错误类型设计，前者决定了你是否该用 %w 把根因一路托上去。
