go代码生成器中error必须为接口类型，需实现error()方法、用%w包装、严格检查err!=nil、避免变量名冲突，并过滤error字段以兼容stringer/easyjson等工具。
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。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 所有生成的 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 检查，少一个变量名隔离，线上就多一个查不出的静默失败。
