正确做法是手动设置响应头、状态码和JSON body；统一错误结构应含trace_id、error_type、hint、code（字符串）、details；panic恢复后须显式设500状态码并注入堆栈到details；需封装工厂函数确保全链路错误出口一致。
Go HTTP handler里怎么返回标准JSON错误
直接用 json.Marshal + http.Error 不行，因为后者会强制设 Content-Type: text/plain 且无法控制状态码细节。正确做法是手动写响应头和 body。
- 先调
w.Header().Set("Content-Type", "application/json; charset=utf-8") - 再调
w.WriteHeader(statusCode)（注意必须在w.Write前） - 最后用
json.NewEncoder(w).Encode(errObj)，比json.Marshal+w.Write更安全（自动处理 error、避免中间 []byte 分配）
统一错误结构体该包含哪些字段
别只塞 message 和 code，生产环境至少要留三个口子：定位问题的 trace ID、区分客户端/服务端错误的 error_type、以及对前端友好的 hint（比如“请重试”或“参数格式错误”）。
code用字符串（如"invalid_param"），别用数字——数字易冲突、难扩展、前端不好做 i18n 映射trace_id必须从 request context 里取（比如用req.Context().Value("trace_id")），不能每次 new- 避免嵌套过深，
details字段用map[string]interface{}或[]string即可，别搞 struct 嵌套
中间件里拦截 panic 并转成 JSON 错误要注意什么
panic 恢复后，HTTP 状态码默认是 200，不显式设 w.WriteHeader 就会返回成功响应，前端完全感知不到出错了。
- recover 后必须立即检查
err != nil，然后调w.WriteHeader(http.StatusInternalServerError) - 不要在 defer 里写日志就完事——得把 panic 堆栈注入到错误结构的
details字段里，否则线上查不出哪行 panic - 注意中间件顺序：recover 中间件必须在所有业务 handler 外层，否则捕不到内层 panic
第三方库（如 echo、gin）里怎么保持自定义错误结构一致
它们的 ctx.JSON 或 c.AbortWithStatusJSON 只负责序列化，不帮你构造结构。统一逻辑还得自己封装。
- 别在每个 handler 里重复 new 错误 struct，写个工厂函数，比如
NewAPIError(code, msg, hint string) APIError - gin 的
c.Error()是用于框架内部错误跟踪的，不是给客户端返回用的，别混淆 - 如果用了 zap 日志，错误结构里的
trace_id要和 zap 的logger.With(zap.String("trace_id", tid))对齐，不然日志串不起来
