ThinkPHP6.1不原生支持跨节点分布式事务，其Db::startTrans()仅作用于单个数据库连接实例，无法自动协调多个物理库的原子提交与回滚；跨库需依赖TCC、本地消息表+补偿或2PC等业务层方案实现最终一致性。
ThinkPHP6.1 本身不原生支持跨节点事务（即真正意义上的分布式事务），它面向的是单库或读写分离场景；跨节点事务必须依赖外部机制或业务层协调，不能靠 Db::startTrans() 直接覆盖多个物理数据库节点。
明确限制：TP6.1 的事务无法自动跨分片/跨库原子提交
即使你配置了多个数据库连接（如分库分表），TP 的 startTrans() 只作用于当前连接实例。对 A 库调用 Db::connect('db_a')->startTrans()，和对 B 库调用 Db::connect('db_b')->startTrans() 是两个完全独立的事务上下文——它们彼此无感知，commit 或 rollback 不会联动。一旦某个库操作失败，其他库已提交的数据无法自动回滚。
可行方案：按业务场景选择适配策略
实际落地需结合数据一致性要求、性能容忍度与系统复杂度权衡：
- 强一致性（金融级）→ TCC 模式：将一个业务操作拆为 try / confirm / cancel 三阶段。例如下单时先冻结库存（try）、支付成功后确认扣减（confirm），失败则解冻（cancel）。需每个服务暴露对应接口，并由协调器（可基于 Redis + 定时任务或 Swoole Worker）管理状态流转。
- 最终一致性（订单+物流类）→ 本地消息表 + 补偿：主库事务内写业务数据 + 写一条“待发消息”到本地消息表；再由独立消费者（如 Think-Swoole 任务）异步投递到 MQ（RabbitMQ/Kafka），下游服务消费后执行动作并回调确认。失败则重试 + 告警 + 人工介入。
- 简化场景（同机房、低并发）→ 2PC 协调器封装：用 Swoole 启一个轻量协调服务，接收事务请求 → 分别向各节点发起 prepare → 收集响应 → 统一发 commit 或 rollback。注意该方案存在单点风险和阻塞问题，仅适合可控环境。
-
对接 TDSQL 等分布式数据库 → 显式路由 + 单分片事务优先：若使用腾讯云 TDSQL，务必配置
deploy=1、hostname指向 Proxy，并确保所有操作都带shardkey（如 user_id）。这样 SQL 会被路由到同一物理分片，TP 的普通事务即可生效；跨分片查询或更新必须手动控制，避免事务失效。
避坑要点：配置与编码细节决定成败
很多问题不是逻辑错，而是配置漏掉导致行为异常：
立即学习“PHP免费学习笔记（深入）”；
- TDSQL 连接必须设
PDO::ATTR_EMULATE_PREPARES => false，否则预处理语句破坏分片键识别，SQL 路由错位； - 开启事务后，
find()等读操作会自动 fallback 到主库（禁用读写分离），避免从库延迟导致查不到刚写入的数据； - 不要在事务中混用
Db::connect('other_db')—— 自定义连接名会脱离全局事务管理，变成孤立连接； - 跨库操作若必须共用事务上下文，只能靠手动维护多个连接的
startTrans/commit/rollback并捕获全部异常，但不推荐用于生产核心链路。
本质上，TP6.1 是工具，不是分布式事务中间件。它提供连接、查询、基础事务能力，而跨节点一致性需要你用模式补足、用监控兜底、用日志留痕。选对方案比写对代码更重要。
