Go语言错误处理与代码生成技巧

本文深入探讨了Go语言代码生成场景中错误处理的关键陷阱与最佳实践，强调error必须严格遵循接口规范（实现Error()方法并用%w包装错误链），避免硬编码为string或结构体以保障errors.Is/As等标准能力；指出HTTP客户端生成代码中nil指针panic的常见根源在于忽略多阶段错误检查（如Do()、status code、JSON解码、body读取），要求每处都立即校验err!=nil并安全处理resp.Body；揭示stringer/easyjson等工具忽略error字段的本质是类型与导出规则限制，建议用ErrMsg/ErrCode替代或手动处理；最后警示变量名冲突风险，提出加前缀、AST扫描动态重命名等方案，直击生成代码“看似能跑、实则静默失败”的线上痛点——每一个疏忽的%w、一次跳过的err判断、一个未隔离的err变量，都可能让故障在生产环境悄然隐身。

Go 代码生成器里怎么处理 error 类型？

生成的 Go 代码如果要和标准库或业务逻辑兼容，error 必须是接口类型，不能硬编码成 string 或自定义结构体。否则调用方用 errors.Is、errors.As 会失效，if err != nil 虽然能过，但后续错误分类、重试、日志上下文都容易断。

实操建议：

• 模板中统一用 error 作为返回类型，别写 *MyError 或 string
• 如果需要带字段（如 code、traceID），让生成类型「实现 error 接口」，即必须有 Error() string 方法
• 避免在模板里直接拼接 fmt.Errorf("failed: %v", x) —— 这会让错误链丢失，改用 fmt.Errorf("failed: %w", x)（%w 才支持 errors.Unwrap）

用 go:generate 生成含错误处理的客户端时，哪些地方容易 panic？

常见现象：生成后一跑就 panic: runtime error: invalid memory address or nil pointer dereference，尤其在 HTTP 客户端里对 resp.Body 做 defer resp.Body.Close() 时没判 err != nil。

原因在于生成器通常只覆盖“成功路径”，而 Go 的 HTTP client 错误不只发生在 Do()，还可能在 resp.StatusCode 判定、JSON 解码、甚至 io.ReadAll 读空 body 时触发 io.ErrUnexpectedEOF。

实操建议：

• 所有生成的 HTTP 请求函数，必须在 resp, err := c.Do(req) 后立刻检查 err != nil，并 return 错误，不能跳过
• resp.Body 只有在 resp != nil && err == nil 时才安全 defer 关闭；否则得先判 resp 是否为 nil
• JSON 解码前加 if resp.StatusCode = 300，别等 json.Unmarshal 报错才处理

用 stringer 或 easyjson 生成代码时，error 字段为什么总被忽略？

典型表现：结构体里有个 Err error 字段，但生成的 String() 方法没打印它，或者 MarshalJSON() 输出里压根没有 "err" key。

根本原因是这些工具默认只处理导出字段（首字母大写）+ 非接口/非函数类型。error 是接口，且多数人写的字段名是小写的 err，直接被跳过。

实操建议：

• 如果真要序列化错误内容，别把 error 当字段塞进结构体——改用 ErrMsg string + ErrCode int 这类可导出、可生成的字段
• 必须保留 error 字段时，别依赖 stringer 打印它；自己在 String() 方法里显式调用 e.Err.Error()
• easyjson 等 JSON 工具不支持 error 字段生成，遇到就报 unsupported type error，提前在模板里过滤掉该字段

自研代码生成器里，如何让错误变量名不和用户代码冲突？

现象：生成的函数里用了 err 作变量名，结果用户在内联 if err := doX(); err != nil { ... } 时，外层 err 被 shadow，导致上游错误被吞。

这不是语法错误，但调试时极难发现——日志里永远只看到最内层的 err，上层错误静默消失。

实操建议：

• 生成器模板里，所有局部 err 变量统一加前缀，比如 genErr、httpErr、jsonErr
• 如果生成的是方法体（不是完整函数），禁止直接声明 err := ...，改用 var genErr error + 赋值，避免覆盖已有作用域
• 更稳妥的做法：生成器输出前做一次 AST 扫描，检查目标文件是否已定义 err，动态换名（比如 err1、err2）

真正麻烦的从来不是“怎么生成 error”，而是生成后它能不能被正确传播、分类、调试。少一个 %w，少一个 err != nil 检查，少一个变量名隔离，线上就多一个查不出的静默失败。

今天关于《Go语言错误处理与代码生成技巧》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！