Golang自定义HTTP错误响应与JSON处理

正确做法是手动设置响应头、状态码和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)) 对齐，不然日志串不起来