在 Go 中，将 *sql.DB 连接传递给数据库操作函数有三种主流方式：声明为全局变量、作为参数显式传入，或封装进结构体作为方法接收者；推荐优先采用参数传递或结构体封装，以提升可测试性与依赖清晰度。
在 go 中，将 `*sql.db` 连接传递给数据库操作函数有三种主流方式：声明为全局变量、作为参数显式传入，或封装进结构体作为方法接收者；推荐优先采用参数传递或结构体封装，以提升可测试性与依赖清晰度。
在 Go 应用开发中，数据库连接（*sql.DB）是典型的共享资源，需被多个函数或模块复用。但直接在函数内部访问未声明的变量（如示例中的 db）会导致编译错误。以下是三种工程实践中常用且各具适用场景的解决方案：
✅ 方案一：通过参数显式传递（推荐初学者与中大型项目）
将 *sql.DB 作为首参传入函数，使依赖关系一目了然，极大提升函数的可测试性与可维护性：
func addRow(db *sql.DB, row Room) error {
stmt, err := db.Prepare("INSERT INTO Rooms (Name, Size, WindowCount, WallDecorationType, Floor) VALUES(?, ?, ?, ?, ?)")
if err != nil {
return err
}
defer stmt.Close() // 关键：防止语句泄露
_, err = stmt.Exec(row.Name, row.Size, row.WindowCount, row.WallDecorationType, row.Floor)
return err
}
// 调用示例
func main() {
db, err := sql.Open("sqlite3", "./house.db")
checkErr(err)
defer db.Close() // 程序退出前关闭连接池
room := Room{...}
err = addRow(db, room)
checkErr(err)
}
⚠️ 注意：务必调用
stmt.Close()（或使用defer），否则预编译语句会持续占用连接池资源；同时*sql.DB本身应全程复用（它已是连接池），无需在每次操作时重新Open。
✅ 方案二：封装为结构体方法（推荐服务化/模块化架构）
当业务逻辑围绕数据库展开时，可定义一个“数据访问层”结构体，将 *sql.DB 作为字段封装，并将操作定义为方法：
type RoomStore struct {
db *sql.DB
}
func NewRoomStore(db *sql.DB) *RoomStore {
return &RoomStore{db: db}
}
func (rs *RoomStore) AddRow(row Room) error {
_, err := rs.db.Exec(
"INSERT INTO Rooms (Name, Size, WindowCount, WallDecorationType, Floor) VALUES(?, ?, ?, ?, ?)",
row.Name, row.Size, row.WindowCount, row.WallDecorationType, row.Floor,
)
return err
}
// 使用
func main() {
db, err := sql.Open("sqlite3", "./house.db")
checkErr(err)
defer db.Close()
store := NewRoomStore(db)
err = store.AddRow(Room{...})
checkErr(err)
}
该模式天然支持依赖注入，便于单元测试（可注入 mock *sql.DB），也利于未来扩展事务、日志、重试等横切逻辑。
❌ 方案三：全局变量（仅限极简脚本或原型验证）
虽然可行，但不推荐用于生产环境：
var db *sql.DB // 全局声明
func main() {
var err error
db, err = sql.Open("sqlite3", "./house.db")
checkErr(err)
defer db.Close()
err = addRow(Room{...}) // 无参数，隐式依赖
checkErr(err)
}
func addRow(row Room) error {
_, err := db.Exec("INSERT ...", row.Name, ...)
return err
}
⚠️ 风险提示：全局变量破坏封装性，导致单元测试困难、并发安全隐患（如误在 init() 中初始化）、难以实现多数据库实例等。
? 总结建议
- 首选方案一（参数传递）：简单直接，零额外类型开销，适合功能解耦明确的中小型项目；
-
进阶选方案二（结构体封装）：更符合 Go 的“组合优于继承”哲学，天然支持接口抽象（如
type RoomStorer interface { AddRow(Room) error }），是构建可维护后端服务的推荐范式； - 避免方案三（全局变量）：除非是单文件 CLI 工具或快速 PoC，否则应主动规避。
无论采用哪种方式，请始终确保：
✅ sql.Open 后调用 db.Ping() 验证连接可用性；
✅ db.Close() 在程序生命周期结束前调用；
✅ 使用 Exec 替代 Prepare + Exec（除非高频重复执行同一语句）以减少开销；
✅ 错误处理不忽略，尤其关注 driver.ErrBadConn 等可重试错误。
