gin.default()不适合生产环境，因其默认启用同步阻塞日志、无堆栈的panic恢复及无法配置超时和优雅关机的r.run()；应改用gin.new()配合http.server自定义配置。
gin.Default() 不适合生产环境启动，它默认加载了日志和 panic 恢复中间件，掩盖错误、拖慢性能、无法控制超时和关闭流程。
别直接用 gin.Default() 启动服务
开发时图省事写 r := gin.Default() + r.Run()，上线后容易出三类问题：
- 日志中间件在高并发下成为瓶颈，
gin.Logger()是同步阻塞写，没缓冲、没采样、不支持结构化 -
gin.Recovery()捕获 panic 后只返回 500，不透出堆栈，线上排查等于盲人摸象 -
r.Run()绕过*http.Server控制权，没法设ReadTimeout/WriteTimeout，也无法优雅关机
生产环境应改用：
r := gin.New()
// 按需加 Recovery，不加 Logger
r.Use(gin.Recovery())
srv := &http.Server{
Addr: ":8080",
Handler: r,
ReadTimeout: 5 * time.Second,
WriteTimeout: 10 * time.Second,
}
log.Fatal(srv.ListenAndServe())
进程退出前必须调 srv.Shutdown()，否则正在写的响应可能被截断。
c.Param()、c.Query()、c.PostForm() 别混用
这三个方法来源完全不同，拿错就空或 panic，Gin 不做类型校验，运行时才暴露：
-
c.Param("id")只取路径参数，如/user/:id对应 URL/user/123→ 返回"123"；若 URL 是/user?id=123，它返回空字符串 -
c.Query("page")取 URL 查询参数，/list?page=2&size=10→"2"；重复 key（如?tag=a&tag=b）只取第一个值，要全量得用c.Request.URL.Query()["tag"] -
c.PostForm("name")仅支持application/x-www-form-urlencoded表单；对 JSON 请求体完全无效，JSON 必须用c.ShouldBindJSON(&v)
常见错误：用 c.PostForm() 解析前端发来的 JSON，结果 v 全零值，且无报错 —— Gin 默认静默失败。
路由分组不是可选项，是模块隔离刚需
单个 r.GET() 写法在接口少时可行，但一过 10 个路由，就会面临三个实际问题：
- 权限难统一：比如所有
/admin/*接口都要 JWT 验证，不靠分组就得每个路由重复r.GET("/admin/user", authMiddleware(), handler) - 前缀易漏：手动拼
/api/v1/user、/api/v1/order，某天加新接口忘了写/api/v1/，版本混乱 - 文档难生成：Swagger 工具依赖路由前缀推断模块归属，扁平路由导致 tag 分组失效
正确写法：
api := r.Group("/api/v1")
{
api.GET("/user", getUser)
api.POST("/user", createUser)
}
<p>admin := r.Group("/admin")
admin.Use(authMiddleware(), roleCheck("admin"))
{
admin.GET("/logs", getLogs)
}
</p>
分组括号里的 {} 是纯视觉提示，不影响逻辑，但团队协作时能一眼识别作用域边界。
r.Run() 默认监听 0.0.0.0:8080，容器里很危险
本地调试没问题，但 Docker 或 Kubernetes 中裸跑 r.Run() 会带来两个隐蔽风险：
- 监听
0.0.0.0意味着绑定所有网卡，若容器网络配置不当，可能把服务暴露给宿主机甚至外网 - 没配
GIN_MODE=release时，gin.Default()会输出[GIN-debug]日志，含路由树、中间件链等敏感信息
建议启动前显式设置：
if os.Getenv("GIN_MODE") == "" {
gin.SetMode(gin.ReleaseMode)
}
r := gin.New()
// ... 路由和中间件
r.Run(":8080") // 显式端口，不依赖默认
更稳妥的做法是用环境变量控制监听地址：r.Run(os.Getenv("ADDR") + ":8080")，K8s Service 可精确控制入口。
真实项目里最常被忽略的不是语法，而是 http.Server 生命周期管理 —— 它不归 Gin 管，但请求中断、连接泄漏、超时堆积都从这儿开始。
