sqlboiler 生成代码不能直接用于微服务多实例场景，因其默认使用全局 db 变量、缺乏 context 支持、连接池配置易失控，需改用显式传参、注入 *sql.db 并封装带 context 的查询逻辑。
SQLBoiler 生成的代码为什么不能直接用在微服务多实例场景？
SQLBoiler 本身不是“驱动”，而是代码生成器，它依赖底层 database/sql 驱动（如 postgres 或 mysql）工作。微服务中真正要解决的不是“引入 SQLBoiler”，而是如何让生成的模型、db 实例、事务上下文与服务生命周期对齐——否则你会遇到连接泄漏、上下文取消失效、测试难 mock 等问题。
- 生成代码默认使用全局
db变量（如models.DB），在多 goroutine/多实例下共享连接池，但缺乏请求级隔离 -
models.NewDB()返回的*sql.DB是线程安全的，但若未统一配置SetMaxOpenConns/SetMaxIdleConns，高并发时可能耗尽数据库连接 - 生成的
Find/One方法默认不接受context.Context，无法响应 HTTP 请求取消或超时
怎么让 SQLBoiler 模型支持 context.Context 和依赖注入？
必须绕过生成代码里的硬编码 db，改用显式传参方式。SQLBoiler 本身不强制绑定全局 db，关键在于调用时传入你自己的 *sql.DB 实例，并封装带 context 的查询逻辑。
- 禁止调用
models.FindUsers这类无 context 参数的快捷方法；改用models.Users(q).All(ctx, db) - 所有数据库操作入口（如 service 层方法）必须接收
ctx context.Context和db *sql.DB两个参数，不要从包变量取 - 若用 Wire/DI 框架，把
*sql.DB注入为 singleton，再通过构造函数传给 repository 结构体，避免每次 new - 示例：
func (r *UserRepo) GetByID(ctx context.Context, id int) (*models.User, error) { return models.Users( qm.Where("id = ?", id), ).One(ctx, r.db) }
SQLBoiler + pgx/v5 能一起用吗？会有什么坑？
可以，但必须用 pgx/v4 或降级适配——SQLBoiler 官方只兼容 pgx/v4（截至 v4.12.0）。v5 的 pgxpool.Pool 不兼容 SQLBoiler 期望的 driver.Conn 接口，强行传入会导致 panic。
- 若坚持用 pgx/v5，只能退回到
*sql.DB+pgx/v5/pgxpool的桥接模式：用pgxpool.Pool的Stat()和Acquire()手动包装成sql.Driver，但 SQLBoiler 不支持这种定制驱动 - 更稳妥做法：用
pgx/v4的pgxpool.Pool，再通过pgxpool.Pool.Stat()获取*sql.DB（SQLBoiler 要求的类型），但注意pgx/v4已归档，不再维护 - 推荐方案：老老实实用
lib/pq或jackc/pgconn+database/sql，SQLBoiler 对它们支持最稳
微服务部署时，SQLBoiler 生成文件该不该进 Git？
应该进，且必须进。生成代码是编译时契约，不是运行时动态产物。CI/CD 中缺失生成文件会导致构建失败，且不同开发者本地生成结果不一致会引发隐性 bug。
- 每次数据库 schema 变更后，必须重新运行
sqlboiler psql并提交新增/修改的models/*.go - 把
sqlboiler.toml和boil_queries.go等模板配置一并提交，确保生成行为可复现 - 禁止在 CI 中自动执行生成步骤：没有人工校验的生成代码可能引入空指针、字段类型错配等 runtime 错误
- 特别注意：如果用了自定义 template（如加了 soft-delete 过滤），这些 template 文件也必须进 Git
ctx 被直接透传到 .All(ctx, db)，但没意识到 db 本身可能来自 long-lived 服务初始化阶段，它的连接池设置、日志 hook、metric collector 都需要与这个 ctx 的语义对齐。这点没法靠生成工具解决，得靠人盯住。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
