应主动构造结构化错误响应：用 JSON 格式返回统一格式如{"code":400,"message":"invalid user id","data":null}，按错误类型设对应状态码（400/404/500），封装 AppError 类型并用中间件处理，严禁泄露敏感信息。
直接返回错误信息给前端
在 Go 的 HTTP 处理函数中，遇到错误时不要 panic 或静默忽略，而应主动构造响应，把错误原因以结构化方式返回。推荐使用 JSON 格式，状态码匹配语义（如 400 表示参数错误，500 表示服务内部异常）：
- 用 http.Error() 快速返回简单文本错误（适合调试或非关键接口）
- 更推荐手动设置 w.WriteHeader(statusCode) + json.NewEncoder(w).Encode()，控制响应体结构
- 统一错误响应格式，例如：{ "code": 400, "message": "invalid user id", "data": null }
区分错误类型做针对性处理
不是所有错误都该返回 500。需识别错误来源，选择合适的状态码和提示：
- 客户端错误（如 JSON 解析失败、必填字段缺失、ID 格式错误）→ 返回 400，并给出可读提示，不暴露内部细节
- 资源未找到（如数据库查不到用户）→ 返回 404，避免泄露是否存在该资源的逻辑（如用 404 而非 400 区分“ID 格式错”和“ID 存在但无数据”）
- 服务端错误（如 DB 连接失败、第三方 API 超时）→ 返回 500，日志记录完整错误栈，响应体只返回通用提示（如 "service unavailable"）
用自定义错误类型封装上下文
原生 error 接口信息有限。可定义带状态码、业务码、消息的错误类型，便于中间件统一处理：
- 定义结构体如 AppError，含 Code（HTTP 状态码）、BizCode（业务码如 "USER_NOT_FOUND"）、Msg 字段
- 在 handler 中主动 wrap 错误：return &AppError{Code: http.StatusNotFound, BizCode: "USER_001", Msg: "user not exist"}
- 配合中间件，在 writeHeader 前拦截 *AppError，自动设置状态码并序列化响应
避免敏感信息泄露
生产环境切忌把原始 error.Error() 直接返回给前端，尤其是数据库错误、文件路径、堆栈等：
立即学习“go语言免费学习笔记（深入）”；
- 开发阶段可在响应中加 "debug": true 字段附带详细错误，但生产环境必须关闭
- 对 error 调用 errors.Is() 或 errors.As() 判断类型，再决定是否记录敏感日志
- 第三方库报错（如 pgx、redis）要提前包装，屏蔽底层驱动细节，转为业务友好的提示
