thinkphp 不支持跨库事务，因事务绑定于单个 pdo 连接，db::connect() 切换后创建独立连接，starttrans() 仅作用于当前连接；跨库操作需应用层补偿而非数据库事务。
ThinkPHP 本身不支持跨库事务，所谓“多数据库读写分离”仅限单库主从场景；跨库操作无法保证原子性，强行用 startTrans() 只会作用于当前连接的数据库。
为什么 Db::connect() 切换数据库后 startTrans() 无效
ThinkPHP 的事务是基于 PDO 连接实例绑定的。每次调用 Db::connect('config_name') 都会创建独立连接，而 startTrans()、commit()、rollback() 只对当前连接生效。跨库操作时，你实际在操作多个互不感知的连接：
- 连接 A（user_db）执行
startTrans()→ 开启事务 - 连接 B（order_db）执行
startTrans()→ 开启另一个事务 - 两个事务彼此隔离，无法协同提交或回滚
常见错误现象：一个库写入成功，另一个库因异常未写入，但程序仍返回“成功”，数据不一致。
读写分离配置只适用于同一逻辑库的主从结构
ThinkPHP 的 'read' => ['192.168.1.10', '192.168.1.11'] 和 'write' => '192.168.1.10' 是为单个数据库（如 myapp）配置主从，所有模型默认访问该库。它不等于“多个业务库”。正确配置示例如下：
'db_config' => [
'default' => [
'type' => 'mysql',
'hostname' => '192.168.1.10',
'database' => 'myapp',
'username' => 'root',
'password' => '123',
'hostport' => '3306',
'read' => ['192.168.1.11', '192.168.1.12'],
'write' => '192.168.1.10',
],
],
注意：database 值仍是单一库名；read/write 控制的是该库的节点路由，不是库名切换。
跨库操作只能靠应用层补偿，不能依赖数据库事务
当必须操作 user_db 和 order_db 两个物理库时，需放弃 ACID 中的 “A（原子性）”，改用以下策略：
- 先写核心库（如 order_db），记录完整上下文到本地日志表（含 user_id、order_sn、状态等）
- 再写关联库（如 user_db），失败则触发异步重试任务
- 提供幂等接口（如按
order_sn查询是否已同步），供对账或人工介入 - 避免在控制器里直接调用多个
Db::connect()并套try/catch—— 这不是事务，只是异常捕获
性能影响：跨库操作天然增加网络往返和协调成本；兼容性上，MySQL 8.0+ 的 XA 事务虽存在，但 ThinkPHP 无封装，且生产环境极少启用（高延迟、易死锁、运维复杂）。
模型指定连接 ≠ 跨库事务支持
给模型设置 protected $connection = 'order_db'; 或在查询时用 UserModel::connect('user_db')->find()，只是切换连接源，不改变事务作用域。以下代码看似“一起操作”，实则毫无事务保障：
Db::connect('user_db')->startTrans();
Db::connect('order_db')->startTrans();
// 各自插入
Db::connect('user_db')->insert([...]);
Db::connect('order_db')->insert([...]);
// 两边都 commit —— 但失败时无法回滚对方
Db::connect('user_db')->commit();
Db::connect('order_db')->commit();
真正容易被忽略的点：开发者常把“能连上多个库”误解为“能跨库事务”，而框架文档也未明确强调此限制。线上一旦出现跨库数据不一致，排查方向容易误入数据库配置或驱动问题，实际根源在架构设计层面就不可行。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
