应定义HTTPStatusError接口统一携带状态码，业务错误实现该接口并在顶层handler中类型断言后调用http.Error；避免goroutine内错误被忽略、json.Marshal后未检查错误导致200静默降级。
HTTP handler里返回带状态码的错误总被忽略
Go 的 http.Error 会直接写响应并结束请求，但如果你在业务逻辑里提前构造了错误（比如校验失败），又想统一透传状态码，用 error 接口本身是做不到的——它不带 HTTP 状态信息。常见现象是：你返回了 errors.New("not found")，但 handler 里没做任何处理，最终默认返回 200 + 空体，前端一脸懵。
真正该做的是让错误自己“携带”状态码，并在顶层 handler 统一识别和响应。别把状态码和错误拆开维护，否则容易错位。
- 定义一个接口，比如
HTTPStatusError，要求实现Error() string和StatusCode() int - 所有业务错误都实现这个接口，例如
NotFoundError返回 404，ValidationError返回 400 - handler 最外层用类型断言判断是否为
HTTPStatusError，再调用http.Error(w, err.Error(), err.StatusCode()) - 别在中间件或 service 层直接调用
http.Error——这会让错误流不可控，也破坏分层
自定义错误类型怎么避免 panic 或 nil 指针
很多人写 type ValidationError struct{ Msg string; Code int }，然后在 StatusCode() 方法里直接返回 e.Code，但忘了初始化时可能传了 nil 指针。更危险的是：用结构体嵌套另一个 error 字段，却没处理其为 nil 的情况，调用 e.Unwrap().Error() 就 panic。
关键不是“能不能嵌套”，而是“谁负责判空”。建议所有自定义错误类型用值接收器 + 零值安全设计：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 状态码字段设默认值，比如
Code int = http.StatusInternalServerError - 错误消息字段用
fmt.Sprintf构造，不依赖外部传入的error字段（除非显式检查非 nil） - 如果必须包装底层 error，
Unwrap()方法开头加if e.err == nil { return nil } - 测试时故意传空字符串、0 状态码、nil error，看会不会 panic 或返回 0 状态码（HTTP 中 0 不合法）
中间件里统一拦截状态码错误为什么总漏掉 goroutine
你在 main handler 外包了一层 recovery 中间件，也写了类型断言逻辑，但异步启动的 goroutine 里发生的错误（比如 go func(){ ... db.Query(...) }()）完全不会进中间件——因为它们不在当前 HTTP 请求的调用栈里。
这类错误根本不会走到你的 handler 返回路径，自然也不会被中间件捕获。最典型的就是日志上报失败、缓存更新失败、消息队列投递失败等后台操作。
- goroutine 内部发生的错误，必须就地处理：记录日志 + 调用
http.Error是错的（w 已失效），应只记录或发告警 - 如果确实需要通知前端，得换同步方式，或改用响应体中带 warning 字段，而不是强求 HTTP 状态码
- 中间件只对主 goroutine 有效；想兜住所有错误，得靠 context 取消 + channel 收集 + 超时控制，但这已超出“错误封装”范畴
json.Marshal 报错导致 500 却显示成 200
这是最容易被忽略的链路断裂点：你构造好了 map[string]interface{} 响应体，调用 json.Marshal 失败（比如含 NaN、未导出字段、循环引用），但没检查错误，直接写了空字节到 response body，状态码还是默认的 200。
HTTP 状态码不会因为 json.Marshal 失败而自动变成 500，Go 的 http.ResponseWriter 也不拦截 write 失败——它静默丢弃错误。
- 每次
json.Marshal后必须检查 err，不为 nil 就立刻http.Error(w, "internal error", http.StatusInternalServerError) - 别依赖 defer 或 recover 捕获 marshal 错误——recover 只抓 panic，而
json.Marshal只返回 error - 如果用
json.NewEncoder(w).Encode(...)，它会在写入时返回 error，但此时 header 可能已发送，无法再改状态码；所以优先用Marshal+ 显式 write
状态码和错误的绑定不是加个字段就完事，关键是整个 HTTP 流程里谁有权限决定状态码、谁负责写响应、谁会提前终止流程。漏掉任意一环，错误就会“静默降级”。
