企业级Gin项目需从gin.Default()演进至可上线服务，必须替换默认Logger（缺traceID、耗时、IP）和Recovery（不落盘、无告警），并显式注册自定义日志、panic告警及白名单跨域中间件。
企业级 Gin 项目不是从 gin.Default() 开始就直接上生产，而是沿着「能跑 → 能稳 → 能查 → 能扩」四步演进。跳过任何一环，后期都会付出数倍维护成本。
从 gin.Default() 到可上线服务：必须替换的两个默认中间件
开发初期用 gin.Default() 没问题，但它自带的 Logger 和 Recovery 不适合生产：
-
Logger输出格式无请求 ID、无耗时毫秒、无客户端 IP，日志无法关联追踪 -
Recovery只打印 panic 堆栈到终端，不记录到文件、不告警、不返回结构化错误 - 它默认允许所有跨域（
Access-Control-Allow-Origin: *），但开启Access-Control-Allow-Credentials: true后，*会被浏览器拒绝
建议在 main.go 中显式注册定制中间件：
r := gin.New() r.Use(customLogger()) // 自定义日志，带 traceID + 耗时 + IP r.Use(recoveryWithAlert()) // panic 时写文件 + 发钉钉/企业微信 r.Use(corsMiddleware()) // 显式控制 origin 白名单，而非 "*"
模型层与服务层拆分：什么时候该把逻辑从 controller 移出去
当 controller 函数里出现以下任意一种情况，就该立刻拆到 service 层：
立即学习“go语言免费学习笔记（深入）”；
- 调用了数据库操作（
db.Create()、db.First()等） - 包含事务控制（
tx := db.Begin()） - 需要复用——比如同一段用户校验逻辑被三个接口调用
- 涉及外部 HTTP 请求（调第三方 API）、缓存读写（
redis.Get()）、消息队列推送
注意：model 层只放结构体定义（type User struct{}）和 GORM Tag，**不放任何方法**；service 层才写 UserService.CreateUser() 这类带副作用的函数。
路由分组与中间件绑定：别把鉴权逻辑写死在 handler 里
JWT 鉴权、RBAC 权限检查这类逻辑，必须通过中间件 + 路由分组实现，而不是每个 handler 里重复写 c.GetHeader("Authorization")：
- 按业务域分组：
v1 := r.Group("/api/v1")，再套一层auth := v1.Group("", authMiddleware) - 敏感操作单独分组：
admin := r.Group("/admin", rbacMiddleware("admin")) - 中间件里解析完 token 后，把用户信息塞进
c.Set("user_id", userID)，后续 service 层直接c.MustGet("user_id").(uint)取值
硬编码鉴权会快速导致 controller 耦合严重，且权限变更时要改十几个文件。
数据库初始化与连接池：GORM 的 SetMaxOpenConns 不是越大越好
很多团队直接设 SetMaxOpenConns(1000)，结果 MySQL 报错 Too many connections。真实限制取决于 MySQL 的 max_connections 配置（默认通常 151）和实际并发量。
- 推荐起始值：
SetMaxOpenConns(50)、SetMaxIdleConns(10)、SetConnMaxLifetime(1h) - 关键点：空闲连接超时（
SetConnMaxIdleTime）必须 短于 MySQL 的wait_timeout（默认 8 小时），否则空闲连接会被 MySQL 主动断开，GORM 下次复用时报invalid connection - 务必在
InitDB()末尾加db.AutoMigrate(&User{})，否则上线后发现表没建，又得手动补迁移
连接池参数不是一次配好就完事，要结合压测 QPS 和 DB 监控里的活跃连接数动态调整——这点最容易被忽略。
