buffalo 默认数据库管理不适用于微服务生产环境，需手动解耦：删 database.yml、用 pop.newconnection 独立建连，迁移改用 pop.migrationbox 显式执行，禁用全局 pop.transaction 中间件，从 app.go init() 移除自动 pop.connect。
Buffalo 的数据库连接管理默认不适合微服务或生产环境，必须手动解耦和重配置。 它用 pop.Connection 全局单例绑定单一数据库，且 buffalo db migrate 命令硬编码依赖 database.yml，无法按 service 切分连接池或动态加载配置。
database.yml 不是配置终点，而是启动陷阱
Buffalo 生成的 database.yml 看似灵活，实则限制极强：
- 所有环境共用同一份文件，无法为
product-service和order-service分别指定不同 host/port/database -
pool和idle_timeout等关键参数被写死，企业级部署要求运行时可调（如通过环境变量注入） - 一旦启用
pop.Transaction(app.DB)中间件，整个请求链路就强制绑定该连接，无法切换到只读副本或分库连接
真正可行的做法是：删掉 database.yml，改用 pop.NewConnection 手动构造连接，并在每个 service 的初始化函数里独立管理。
如何绕过 buffalo db migrate 实现可控迁移
buffalo db migrate 是开发便利工具，不是生产迁移方案。它不支持回滚、无明确 exit code、无法指定目标版本，也不兼容多数据库并行执行。
- 把 migration 文件从
models/migrations/移出，改为按 service 组织：如services/product/migrations/ - 用
pop.MigrationBox手动加载迁移路径：box := pop.NewMigrationBox("./services/product/migrations") - 执行迁移时显式传入连接：
box.Up(db)或box.Down(db, 1)，避免隐式依赖全局app.DB - 失败时检查
err并直接 os.Exit(1)，确保 CI/CD 流程能感知失败
PopTransaction 中间件必须按需启用
app.Use(pop.Transaction(app.DB)) 是 Buffalo 默认加的中间件，但它会为每个请求自动开启事务——这在 API 场景下完全多余，且造成连接池争抢。
- 仅在明确需要事务的 handler（如订单创建）中手动调用：
tx, _ := app.DB.Transaction() - 禁用全局中间件后，
app.DB仍可作为只读连接使用，但不再自动 wrap 每个请求 - 若 service 需要多数据源（如主库写 + 日志库写），必须放弃
pop.Transaction，改用sql.Tx手动控制
最易被忽略的一点：Buffalo 启动时会自动调用 pop.Connect 初始化 app.DB，哪怕你后续完全不用它。这个行为藏在 app.go 的 init() 函数里，不翻源码根本看不到——想彻底解耦，得从那里开始删。
