ThinkPHP事务不会自动回滚，必须显式调用rollback()或使用Db::transaction()闭包；若用startTrans()需手动配对commit/rollback；MyISAM引擎不支持事务，测试前须确认表引擎为InnoDB。
事务开启后没调用 rollback() 就结束请求，数据不会自动回滚
ThinkPHP 的事务不是“自动兜底”机制，而是显式控制流。只要没手动触发 rollback()，哪怕抛出异常、脚本中断或 return 退出，只要没走到 rollback 那一步，commit() 就可能被隐式执行（尤其在 PDO 默认 auto-commit 模式下）。
- 常见错误现象：
Db::transaction()包裹的代码里 throw Exception，但没 catch + rollback，结果数据写进去了 - 正确做法：必须用 try-catch 显式包裹，并在 catch 中调用
Db::rollback() - 更稳妥写法是用闭包方式：
Db::transaction(function () { ... })，它会在异常时自动 rollback，但注意——这个自动只对闭包内抛出的未捕获异常生效，如果闭包里自己 catch 了却没 re-throw，就不会 rollback - 闭包方式底层依赖
set_error_handler和异常拦截，若项目启用了自定义错误处理器或 error_reporting 被调低，可能失效
测试回滚时用 dd() 或 dump() 中断流程，会导致事务卡住
开发中常在事务中间加 dd('here') 看状态，但这会让 PHP 进程终止而未释放事务，连接池里的 PDO 实例仍处于 “transaction active” 状态，下次复用该连接时会报错 There is no active transaction 或直接失败。
- 使用场景：本地调试事务逻辑，尤其是想确认某步之后数据是否真没落库
- 替代方案：改用日志记录 + 主动 rollback，例如
Log::info('before update', ['data' => $data]); Db::rollback(); - 切勿在事务中依赖
exit、die、dd、dump等终止执行的函数 - 如果非要看中间态，可在事务外查库（另起一个无事务连接），或用
Db::getLastSql()看生成的 SQL 是否符合预期
Db::startTrans() 和 Db::transaction() 的行为差异影响测试可靠性
两者都开启事务，但嵌套处理、异常传播、资源清理逻辑不同，混用容易导致 rollback 失效或重复 commit。
-
Db::startTrans()是手动模式：需配对调用commit()/rollback()，不自动捕获异常，适合复杂分支逻辑 -
Db::transaction()是自动模式：仅支持单层闭包，内部异常会触发 rollback，但无法在闭包外做条件判断后再决定是否提交 - 容易踩的坑：在
Db::transaction()闭包里又调用Db::startTrans()，ThinkPHP 不支持嵌套事务（PDO 层也不支持），第二次 startTrans 会被忽略，rollback 时只退到第一层 - 性能提示：闭包方式每次都会新建 PDOStatement 并重置连接状态，高并发下比手动模式略重，但对测试影响可忽略
MySQL 引擎不支持事务，回滚测试永远失败
用 MyISAM 表做回滚测试，无论代码怎么写，rollback() 都静默成功但实际无效——因为 MyISAM 不支持事务，START TRANSACTION 和 ROLLBACK 在它上面是空操作。
- 验证方法：执行
SHOW CREATE TABLE `user`，看输出里是ENGINE=InnoDB还是ENGINE=MyISAM - 建表时务必指定引擎：
protected $type = 'InnoDB';（模型类）或迁移文件中写$table->engine = 'InnoDB'; - ThinkPHP 6+ 默认建表用 InnoDB，但老项目迁移、手动建表、或 DBA 统一配置禁用 InnoDB 时，仍可能踩坑
- 兼容性注意：部分共享主机或低配 MySQL 实例默认关闭 InnoDB，需检查
SHOW ENGINES;输出中InnoDB的 Support 是否为YES
事务回滚测试真正难的不是写代码，而是确保整个链路——从表引擎、连接复用、异常传播路径，到调试手段——都不绕过 rollback 的触发条件。漏掉任意一环，看起来“测了”，其实根本没测到。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
