http状态码需精准语义化：400表请求解析失败（如json格式错），422表业务校验失败（如邮箱已存在）；避免冗余code字段，确保状态码与响应头一致；重定向仅用于浏览器跳转场景，restful api禁用3xx。
HTTP 状态码不是装饰品，它直接决定前端怎么处理你的响应、网关怎么重试、监控怎么告警——用错 400 和 422，前端就得多写三份错误解析逻辑。
什么时候该用 400，什么时候必须用 422
Go 的 net/http 默认只认 400，但 RESTful API 里它俩分工明确：400 表示请求根本没法被解析（比如 JSON 格式错误、Content-Type 缺失），422 表示请求能解出来，但业务规则不通过（比如邮箱格式对，但数据库里已存在）。
常见错误现象：所有校验失败都返回 400，结果前端看到 400 就清空整个表单，而实际只是 password_confirmation 不匹配——这属于语义丢失。
- 用
json.Unmarshal失败 →400 - 用
validator.v10或自定义校验失败 →422 - 路径参数
:id是字符串但期望整数 →400（解析阶段失败） -
id=123解析成功，但查不到对应资源 → 这是404，不是400或422
gin.Context.AbortWithStatusJSON 的陷阱
很多人以为只要调了这个函数，状态码就稳了。但 Gin 在中间件链里如果之前已经写了响应头（比如日志中间件调了 c.Writer.WriteHeader），再调 AbortWithStatusJSON 就会 panic 或静默失效。
立即学习“go语言免费学习笔记（深入）”；
使用场景：常用于统一错误处理中间件，但必须确保它在写响应前执行。
- 永远把校验和错误响应逻辑放在
Bind或ShouldBind之后立即处理，别等进 handler 再判断 - 避免在多个中间件里重复调
AbortWithStatusJSON，Gin 不支持覆盖已发送的状态码 - 如果用了
gin.BasicAuth等内置中间件，注意它们可能提前写 header，需调整中间件顺序
自定义错误响应结构要不要带 status 字段
别加。HTTP 状态码本身已是标准语义层，额外塞个 "status": "error" 或 "code": 422 属于冗余且易错——前端该看 response.status，不是 response.body.code。
性能影响：多序列化一个字段，小到忽略不计；但兼容性风险大：某些 HTTP 客户端（如旧版 OkHttp）会因 body 里 code 和响应头不一致而拒绝解析。
- 响应体只保留业务字段：
message、details（字段级错误）、trace_id - 所有状态码由
http.ResponseWriter.WriteHeader或框架方法控制，绝不靠 body 传递状态意图 - 如果团队坚持要
code字段，必须保证它和 HTTP 状态码严格映射，且文档里写死“此字段仅作参考，以响应头为准”
测试时容易漏掉的边界：重定向与状态码冲突
用 http.Redirect 或 Gin 的 c.Redirect 时，默认发的是 302，但如果你手动设成 301 或 307，又没注意请求方法是否允许重定向，前端可能把 POST 变成 GET，导致数据丢失。
使用场景：仅限登录跳转、短链服务等明确需要浏览器行为干预的地方；RESTful API 的错误响应、成功创建资源等，一律不用重定向。
- API 接口返回
3xx状态码 = 主动放弃 REST 约束，除非你真在做网关或代理层 - 测试时用
httptest.NewRecorder检查Code字段，别只看 body 是否含预期文本 - Gin 的
c.Status(201).JSON(...)比c.JSON(201, ...)更安全——后者依赖默认状态码，中间件可能干扰
状态码选错最麻烦的不是报错，而是它不报错：请求通了，前端逻辑跑偏，问题压到联调甚至上线才暴露。尤其是 409 和 412 这种冷门但关键的码，一用错，分布式锁或乐观并发就失效。
