Buffalo 的数据库模型管理强制单库单连接，不支持多数据库隔离、自定义事务控制、分库迁移及关联预加载的精细化查询。
buffalo g model 生成的模型默认绑定单一数据库
Buffalo 的 buffalo g model 命令会直接在 models/ 目录下生成结构体、migration 文件，并自动注册到全局 pop.Connection。这意味着所有 model 都共享同一个数据库连接池和配置，无法为不同 service 或 domain 指定独立 DB 实例。
常见错误现象：你执行 buffalo g model User 后，在 models/user.go 里看到的 func (u *User) TableName() string 返回的是硬编码表名，而没有机制声明“这个 model 属于 orders_db”或“那个属于 auth_db”。
- 所有 model 必须共用
database.yml中定义的同一套连接参数（development/test/production） - 迁移命令如
buffalo pop migrate up总是作用于当前环境的默认连接，无法指定 target DB - 如果你手动改
models.DB为另一个 pop connection，会导致buffalo dev启动失败——因为框架内部初始化时已强依赖原始连接
pop.Transaction 中间件强制注入全局事务上下文
Buffalo 默认在 app.go 的 PreWares 中启用 popmw.Transaction(models.DB)，它会为每个 HTTP 请求自动开启并提交/回滚事务。这在单体应用中看似方便，但在微服务场景下极易引发问题：
- 事务生命周期与 HTTP 请求强绑定，无法支持跨 service 的 Saga 补偿逻辑
- 调用外部 gRPC 接口失败后，本地事务已提交，无法回滚——
pop.Transaction不提供手动控制点 - 若你在 handler 中调用另一个 service 的 API 并等待响应，该请求的 context 里已有 pop transaction，但下游 service 完全感知不到，数据一致性无保障
你不能通过中间件选项关闭它，也不能替换为自定义的 transaction wrapper；它是硬编码进 popmw 包里的行为。
model 关联预加载（Preload）依赖全局 pop 连接
Buffalo 的 pop ORM 使用 HasMany/BelongsTo 等 tag 声明关联，但预加载必须走 models.DB.Eager().All(&users) 这类调用。问题在于：
-
models.DB是全局变量，所有预加载都复用同一连接池，无法按业务隔离 - 关联字段命名必须严格匹配 pop 的约定（如
user_id），否则Eager()静默失效，返回空 slice 而不报错 - 没有原生支持
JOIN条件过滤（例如只预加载 status=active 的订单），只能靠多次查询 + 内存过滤，性能差
示例：你想查用户及其最近 3 个订单，pop 不支持 LIMIT 子句嵌套在预加载中，你得先查用户，再对每个用户发一条 SELECT ... ORDER BY created_at DESC LIMIT 3 —— N+1 无法避免。
迁移文件无法分库管理，且不支持多环境回滚
buffalo pop generate 创建的 migration 文件统一放在 migrations/ 下，文件名带时间戳，但没有任何字段或注释标明该 migration 归属哪个数据库。更关键的是：
- 执行
buffalo pop migrate down只能回退最新一条，不支持指定版本号或按 service 分组回退 - 没有
--database=orders这类参数，无法将 migration 分发到不同 DB 实例 - SQL 文件内容是纯 DDL，不包含任何条件判断（比如 “仅当表不存在时创建”），在 CI/CD 多次部署时容易报错
如果你试图手动修改 migration SQL 加上 IF NOT EXISTS，buffalo 不会阻止，但下次 generate 出的新文件又会是裸语句——维护成本陡增。
Buffalo 的数据库模型管理本质是单体设计，它的便利性全部建立在“一个应用、一个数据库、一个团队”的前提下。一旦涉及多库、多服务、异构存储或需要精细控制事务边界，这些封装就从助力变成枷锁。最常被忽略的一点是：它没有提供任何 hook 或 interface 让你替换底层 ORM，所有操作都锁定在 pop 的抽象层内。
