选 gin：性能好、生态成熟、开发效率高；RESTful 路由须用 HTTP 方法+名词路径；JSON 绑定推荐 ShouldBindJSON 并手动处理错误。
用 net/http 还是 gin？选型前先看这三点
Go 原生 net/http 足够轻量、稳定，适合简单接口或对依赖极度敏感的场景；但写路由、绑定参数、中间件要手动处理，容易重复造轮子。gin 是最常用的 Web 框架，性能好、生态成熟，gin.Context 封装了请求生命周期关键操作，开发效率高。如果你需要快速交付带鉴权、日志、JSON 验证的接口，直接上 gin 更省心——它不是“必须”，但绝大多数 RESTful 项目里，它比手撸 net/http 少踩 80% 的坑。
注意：别用 echo 或 fiber 替代 gin 做入门练习，文档和社区示例严重偏向 gin，遇到 binding 错误或 middleware 执行顺序问题时，搜不到有效答案的概率翻倍。
定义 RESTful 路由时，别把动词塞进路径里
常见错误是写成 /user/getById?id=123 或 /deleteUser/123 ——这根本不是 RESTful。正确做法是用 HTTP 方法 + 名词资源路径：
-
GET /users→ 列表 -
GET /users/123→ 单条 -
POST /users→ 创建（body 传 JSON） -
PUT /users/123→ 全量更新 -
PATCH /users/123→ 局部更新 -
DELETE /users/123→ 删除
gin 中这样注册：
立即学习“go语言免费学习笔记（深入）”；
r := gin.Default()
r.GET("/users", listUsers)
r.GET("/users/:id", getUser)
r.POST("/users", createUser)
r.PUT("/users/:id", updateUser)
r.DELETE("/users/:id", deleteUser)
路径里的 :id 是通配符，c.Param("id") 取值；别写成 /users/:id/（结尾斜杠），某些代理或测试工具会因末尾斜杠不一致导致 404。
JSON 绑定出错时，ShouldBindJSON 和 BindJSON 差在哪
这是新手最常卡住的地方：ShouldBindJSON 不会自动返回 400，它只校验并填充结构体，错误需手动处理；BindJSON 则会自动写入 400 响应并中止后续逻辑——但前提是没提前调用过 c.Next() 或写过响应头。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
推荐统一用 ShouldBindJSON，因为你能控制错误格式（比如统一加 "code": 4001 字段），也方便加日志：
var req CreateUserReq
if err := c.ShouldBindJSON(&req); err != nil {
c.JSON(400, gin.H{"code": 4001, "msg": "参数错误", "detail": err.Error()})
return
}
注意：结构体字段必须首字母大写 + json tag，否则绑定永远为空：
type CreateUserReq struct {
Name string `json:"name" binding:"required"`
Email string `json:"email" binding:"required,email"`
}
漏掉 binding tag 或写成 json:"name" 但字段是 name string（小写），绑定就静默失败。
启动服务时，别忽略端口占用和 graceful shutdown
本地调试常写 http.ListenAndServe(":8080", r)，但生产环境必须支持平滑重启。gin 默认不带 graceful shutdown，得自己包一层：
srv := &http.Server{
Addr: ":8080",
Handler: r,
}
go func() {
if err := srv.ListenAndServe(); err != nil && err != http.ErrServerClosed {
log.Fatalf("listen: %s\n", err)
}
}()
// 等待 OS 信号，收到 SIGINT/SIGTERM 后关闭
quit := make(chan os.Signal, 1)
signal.Notify(quit, syscall.SIGINT, syscall.SIGTERM)
<-quit
log.Println("Shutting down server...")
srv.Shutdown(context.Background())
另外，:8080 在 Docker 或 CI 环境里可能被占，建议从环境变量读取端口：os.Getenv("PORT")，默认 fallback 到 "8080"。还有，别在 main() 里用 log.Fatal 启动，它会直接 exit，跳过 defer 和 shutdown 流程。
真正难的不是写接口，而是让每个 c.Param、c.Query、c.ShouldBindJSON 都有对应错误分支，且所有错误都走同一套响应结构——这点多数示例代码都故意省略了，但上线后第一个 500 就会暴露出来。
