微服务关键在于结构清晰、职责单一、可独立部署，而非框架堆砌；gin仅处理http请求，需手动实现服务注册、熔断等能力，并重视路由分组、依赖初始化、错误处理与上下文超时控制。
微服务不是靠框架堆出来的，Gin 本身不提供服务注册、熔断、链路追踪这些能力，它只负责把 HTTP 请求跑通。你用 Gin 写出的每个独立进程，要能称为“微服务”，关键在于结构清晰、职责单一、可独立部署——而流程上最容易卡住的，是路由组织、依赖初始化顺序和错误处理边界。
gin.Default() 和 gin.New() 怎么选
刚起步时直接用 gin.Default() 没问题，它自带 Logger 和 Recovery 中间件，适合本地调试。但上线前必须切到 gin.New()，否则 Recovery 会吞掉 panic 后的原始堆栈，线上排查超难。
- 开发阶段：
gin.Default()快速验证逻辑，日志带请求耗时、状态码，省心 - 生产环境：
gin.New()+ 手动注册中间件，比如自定义 error handler、trace 注入、更严格的 panic 捕获（记录到 Sentry 或 Loki） - 注意：
gin.Default()的 Logger 默认输出到 stdout，K8s 日志采集依赖这个格式；如果重定向了 os.Stdout，日志可能丢失
路由分组与版本控制怎么落地
别在 main.go 里写满 r.GET，那是单体写法。微服务必须按业务域或 API 版本做分组，否则加个新接口就得改入口文件，协作冲突高。
- 推荐结构：
v1 := r.Group("/api/v1")，所有 v1 接口挂下面；后续升级 v2，新建v2 := r.Group("/api/v2")，老接口不动 - 分组中间件要按需绑定：比如
v1.Use(authMiddleware())，但健康检查/healthz必须挂在根路由，不能被 auth 拦住 - 路径参数别嵌太深：
/api/v1/users/:id/orders/:order_id看似 RESTful，实际增加客户端解析成本，也难做统一限流；优先扁平化，用 query 参数传关联 ID
数据库连接和 GORM 初始化时机
GORM 实例不能在 handler 里临时创建，也不能全局变量裸奔。初始化必须在服务启动早期完成，并确保连接池复用。
- 正确做法：在
main()函数开头调用gorm.Open()，返回 *gorm.DB，作为依赖注入进 controller 或 service 层 - 常见错误：
db, _ := gorm.Open(mysql.Open(dsn), &gorm.Config{})忘记传&gorm.Config{PrepareStmt: true}，导致预编译失效，QPS 上不去 - 连接池配置必须显式设：
sqlDB, _ := db.DB(); sqlDB.SetMaxOpenConns(10); sqlDB.SetMaxIdleConns(5)，否则默认 0（无上限），容易打爆 MySQL - 别在 handler 里用
db.WithContext(c.Request.Context())就完事——得确保上层中间件已把 context 超时和取消信号传下去，否则 DB 查询不会随请求中断
中间件链里 panic 恢复和错误透传
Gin 的 Recovery 中间件只是兜底，不能替代业务错误处理。真正的难点在于：如何让自定义错误（比如 ErrNotFound）不被 Recovery 捕获，又能统一转成 404 响应？
- 方案：定义业务错误类型，实现
error接口，再写一个中间件拦截它：if errors.Is(err, ErrNotFound) { c.AbortWithStatusJSON(404, gin.H{"error": "not found"}) } - panic 后的 Recovery 要补全 traceID：
c.MustGet("trace_id").(string)，否则日志里找不到上下文 - 别在中间件里直接
log.Fatal，这会让整个服务退出；应该c.Abort()后交由顶层 error handler 统一响应
最常被跳过的一步是：没给每个 handler 显式设置 context 超时。哪怕用了 c.Request.Context()，也要在中间件里调用 context.WithTimeout 包一层，不然数据库慢查询或下游 HTTP 调用卡住，整个 goroutine 就悬着不动。这个细节在线上压测时才暴露得最彻底。
