http.Error不适合统一错误处理，因其只能写死状态码和文本，无法携带错误码、业务上下文、本地化消息，且调用后立即写响应并关闭连接，阻断后续中间件或defer执行；真实项目需记录带trace ID的日志、返回含code/message的JSON、错误降级等，均无法实现。
为什么 http.Error 不适合做统一错误处理
它只能写死状态码和文本，无法携带错误码、业务上下文、本地化消息，且一调用就直接写响应体并关闭连接，后续中间件或 defer 都无法干预。真实项目里你经常需要：记录错误日志时带上 trace ID、返回 JSON 格式含 code 和 message 字段、对某些错误降级返回默认值——这些 http.Error 做不到。
定义可序列化的错误类型：用结构体代替字符串
不要用 errors.New 或 fmt.Errorf 直接抛裸错误。定义一个实现 error 接口的结构体，包含 Code（int）、Message（string）、Details（map[string]interface{}）等字段。关键点：
-
Code必须全局唯一且语义明确，比如1001表示“用户未登录”，2003表示“订单不存在”——不建议用 HTTP 状态码直接当业务码 - 重写
Error()方法，只返回Message，避免日志里刷出大段 JSON - 提供
WithDetail(key, value)方法，方便在 handler 里动态附加请求参数、SQL 错误等调试信息
中间件拦截 panic 和 error 并标准化输出
在路由最外层加一层中间件，统一捕获两类异常：
- 显式返回的
*AppError类型错误（比如从 service 层 return 上来的） - 未预期的 panic（如空指针、数组越界），用
recover()捕获后转为500-INTERNAL_ERROR级别的*AppError
该中间件决定最终响应格式：HTTP 状态码映射靠 AppError.Code 查表（如 1001 → 401，5001 → 500），Body 固定为：
{"code":1001,"message":"用户未登录","details":{}}
。注意别把敏感字段（如数据库密码、token 原文）塞进 Details。
