应使用 wire 实现依赖注入而非全局变量，因 global.db 并发不安全、难以 mock 测试、无法按请求控制连接生命周期且违背依赖倒置原则；wire 通过显式 provider 链（如 newdb → userrepository → userservice → handler）保障类型安全、可测可控。
别用全局变量注入 GORM 实例，Wire 才是 Gin 项目里真正可控、可测、可维护的注入方式。
为什么 global.DB 是个危险信号
看到 global.DB = core.NewDB() 这种写法，第一反应不是“省事”，而是“并发不安全”和“测试难 mock”。Gin 的 handler 是并发执行的，global.DB 没有作用域隔离，一旦某个中间件或 service 层意外覆盖或误改它（比如调用 db.Session(&gorm.Session{}) 后忘了复位），下游所有请求都可能拿到错的会话配置。更麻烦的是单元测试：你没法给每个 test case 注入一个干净的、带 mock 行为的 *gorm.DB。
- 无法控制连接生命周期（比如事务嵌套、超时设置按请求粒度生效）
- 日志、插件、回调等配置被所有请求共享，容易互相污染
- 模块间隐式依赖，service 层直接 import
go-wire/global，违背依赖倒置原则
Wire 的 inject.go 怎么写才不翻车
Wire 不是魔法，它靠显式构造函数链生成初始化代码。关键点在于：**把 *gorm.DB 当作一个普通依赖来声明，而不是“全局单例”。**
- 定义 Provider 函数，返回
*gorm.DB，且只在该函数里调用gorm.Open()和连接池设置 - 所有需要 DB 的组件（如
UserRepository、UserService）都通过构造函数参数接收*gorm.DB，不碰任何 global 包 -
wire.Build()里按依赖顺序列出所有 Provider，Wire 自动拓扑排序并生成InitializeDB()类似函数
示例片段（非完整）：
// wire.go
func InitializeApp() (*gin.Engine, error) {
wire.Build(
NewDB,
NewUserRepository,
NewUserService,
NewUserHandler,
router.RegisterRoutes,
)
return nil, nil
}
func NewDB() (*gorm.DB, error) {
db, err := gorm.Open(mysql.Open(dsn), &gorm.Config{...})
if err != nil {
return nil, err
}
sqlDB, _ := db.DB()
sqlDB.SetMaxIdleConns(10)
sqlDB.SetMaxOpenConns(100)
return db, nil
}
Gin handler 怎么拿到注入后的 DB 实例
Handler 本身不能直接依赖 *gorm.DB —— 它是 HTTP 层，应该只持有业务逻辑封装好的 service。正确链路是：handler → service → repository → *gorm.DB。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要在 handler 里写
global.DB.First(...)，这等于又绕回全局模式 - handler 构造时由 Wire 注入
UserService，而UserService构造时又被注入UserRepository，最终UserRepository拿到*gorm.DB - 如果某个 handler 确实需要临时 DB（比如健康检查 ping），可单独定义一个轻量级
HealthChecker，由 Wire 注入 DB，而非让 handler 直接持有
典型错误写法：h.service.db.Create(...) —— service 层不该暴露 db 字段；正确做法是 h.service.CreateUser(...)，内部由 repository 封装具体操作。
Wire 生成失败最常见的三个原因
运行 wire 命令报错，90% 都卡在这三类问题上：
- Provider 函数签名不匹配：比如
NewDB()返回(*gorm.DB, error)，但某个 service 的构造函数参数写成db *sql.DB（类型不一致） - 循环依赖：A 依赖 B，B 又依赖 A —— Wire 无法解析，必须拆出公共接口或调整层级（例如把 shared logic 提到独立包）
- 未导出类型参与注入：Wire 只能处理首字母大写的导出类型，
type userRepository struct{...}不行，得是type UserRepository struct{...}
Wire 不会帮你自动修复设计问题，它只是把你的依赖图“诚实翻译”成 Go 代码。图本身有问题，生成就失败。
真正难的不是写 Wire 配置，而是把 DB 生命周期、事务边界、上下文传递这些概念从“全局一把抓”切换到“按请求/按场景精细控制”。一旦跨过这个认知门槛，后续加中间件、切面、可观测性，都会自然得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
