必须用 r.Group() 因其可隔离资源生命周期，支持版本控制、嵌套路由与中间件管理；c.ShouldBindJSON() 需强类型结构体保障类型安全与校验；HTTP 状态码须语义化精确返回（如404、201、422），避免全用200。
Go 写 RESTful API，不是把 handler 堆起来就能叫“规范”——真正影响长期可维护性的，是路由分组方式、状态码使用粒度、结构体字段控制这三件事。其他都算锦上添花。
为什么必须用 r.Group() 而不是直接 r.GET()
直接在根引擎上注册 r.GET("/users", h.GetUser) 看似省事，但一加版本、一加权限、一加中间件就崩。Gin 的 r.Group() 是唯一能隔离资源生命周期的机制。
- 版本升级时，只需新建
r.Group("/api/v2")，旧路由不受影响 - 嵌套资源（如订单属于用户）必须用子 Group：
users := r.Group("/users"); orders := users.Group("/:user_id/orders")，避免手动拼接路径导致参数错位 - Group 内混用不同资源（比如在
/usersGroup 里注册GET("/products")）会让 Prometheus 监控打标失效、OpenAPI 文档生成错乱
c.ShouldBindJSON() 为什么不能配 map[string]interface{}
用 map[string]interface{} 接收请求体，等于主动放弃类型安全、IDE 自动补全、字段校验和文档生成能力。所有入参必须走强类型结构体。
- 结构体字段必须带
json:标签，漏掉就会解码为空，比如Name string `json:"name"` - 必填字段加
binding:"required"，如Email string `json:"email" binding:"required,email"`，c.ShouldBindJSON()会自动返回 400 - 禁止在 handler 里手动调用
json.Unmarshal()，否则绕过 Gin 错误拦截，400 不进日志、不触发统一错误中间件
HTTP 状态码不能只靠 200 和 500
客户端靠状态码做重试、缓存、路由判断。返回全用 200 + {"code": 404}，前端 fetch 的 response.ok 永远为 true，错误流控彻底失效。
立即学习“go语言免费学习笔记（深入）”；
- 资源不存在必须用
http.StatusNotFound（404），不是 200 + null - 创建成功必须用
http.StatusCreated（201），并设Locationheader：c.Header("Location", "/api/v1/users/"+id) - 业务校验失败（如邮箱格式不对）优先用
http.StatusUnprocessableEntity（422），比 400 更语义化；限流用http.StatusTooManyRequests（429） - 数据库连接失败应返回
http.StatusServiceUnavailable（503），500 只留给未捕获 panic
最容易被忽略的是路径参数提取和结构体零值覆盖问题：用 c.Param("id") 提取时没校验是否为数字，或 PUT 更新时结构体字段没设指针+omitempty，会导致 DB 原值被零值意外清空。
