mysql不支持事务嵌套，第二层db::transaction()会隐式提交第一层；唯一可行方案是savepoint，它在当前事务内设标记点，配合rollback to savepoint实现局部回滚，且需php层手动捕获异常并显式回滚。
Hyperf协程中MySQL事务不能嵌套，用SAVEPOINT代替
Hyperf里写两个DB::transaction()，第二层不会嵌套，而是隐式提交第一层——数据已经落库，ROLLBACK救不回来。这不是协程的问题，是MySQL本身不支持事务嵌套。
真正能用的只有SAVEPOINT：它不开启新事务，只在当前事务内打标记点，适合“批量操作中单条失败、局部回滚”的场景。
-
SAVEPOINT名必须是静态字符串，不能是变量拼接（如sp_@i会报错） - 每个
SAVEPOINT名在事务内必须唯一，重复声明会覆盖前一个 - 事务
COMMIT或ROLLBACK后，所有SAVEPOINT自动失效 - MyISAM表不支持
SAVEPOINT，执行无效果，先查引擎：SHOW CREATE TABLE users;
DECLARE HANDLER在存储过程中捕获异常，但Hyperf里不推荐
你在Hyperf里写MySQL存储过程并用DECLARE EXIT HANDLER FOR SQLEXCEPTION，逻辑上可行，但实际项目中基本不用——因为Hyperf的事务控制主战场在PHP层，不是数据库层。
存储过程异常处理难调试、难测试、难和协程生命周期对齐，一旦出错，死锁或超时往往卡在连接池里，而不是报错。
- 应用层异常捕获更可控：用
try/catch包裹DB::transaction()，靠PHP异常类型区分业务错误和数据库错误 - MySQL错误码（如1062主键冲突）应由PHP层解析
$e->getCode()或$e->getMessage()后决策，而非塞进存储过程 - 若真要用存储过程，务必关掉
AUTOCOMMIT，且避免在过程里执行CREATE TABLE等隐式提交语句
Hyperf中事务异常必须手动ROLLBACK，框架不自动处理
Hyperf的DB::transaction()只是语法糖，底层仍是START TRANSACTION + COMMIT/ROLLBACK。它不会在异常时自动回滚，也不会帮你重试——出错后不显式ROLLBACK，连接可能长期持有锁，引发死锁。
- 务必在
catch块里调用DB::rollBack()，不要依赖finally里判断是否已提交 - 协程环境下，事务绑定的是当前协程的数据库连接，跨协程
DB::rollBack()无效 - 长事务是死锁温床：转账类逻辑别在事务里做HTTP调用、文件读写或sleep，这些会让锁持有时长不可控
- 启用
innodb_print_all_deadlocks = ON，死锁详情会输出到MySQL error log，比猜SQL顺序靠谱得多
异常处理器里别吞掉数据库异常，要分层响应
你在config/autoload/exceptions.php里注册了自定义ExceptionHandler，如果isValid()无差别返回true，就会把PDOException也当成业务异常处理，导致500响应掩盖了真实的SQL问题。
- 先判断异常类型：
if ($throwable instanceof PDOException)，再决定是否记录SQL、回滚事务、还是透传给上层 - HTTP状态码别直接用
$throwable->getCode()，比如MySQL错误码1205（死锁）不是HTTP状态码，应统一返回500，业务码放JSON body的code字段 - 调用
$this->stopPropagation()前，确认你真的要终结这个异常；否则HttpExceptionHandler收不到404，前端永远收不到正确状态码 - 日志里记清楚：是哪个协程ID、哪条SQL、影响了哪些行（可用
DB::getPdo()->lastInsertId()或DB::raw('ROW_COUNT()')辅助）
catch里亲手敲下DB::rollBack()，并确保它真被执行了。
