Golang RESTful API开发，如何实现语义化状态码的最佳实践？

本文共计1117个文字，预计阅读时间需要5分钟。

HTTP 链接

什么时候该用 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 的陷阱

很多人以为只要调了这个函数，状态码就稳了。