我会保存 SHOW ENGINE INNODB STATUS 的 latest deadlock 或开启死锁日志，拿到两边 SQL、事务持有的锁、等待的索引记录和被回滚的一方。再把 SQL 映射回支付回调与退款代码，确认是否一个先更订单再更支付单，另一个顺序相反。

修复通常是所有路径按同一顺序访问资源，例如都先锁订单、再锁支付记录；查询条件补正确索引，避免锁住比预期更多的行或 gap；远程调用、消息发送移出数据库事务。

应用层会捕获死锁错误做 有限次数、带抖动的整体事务重试，因为被回滚事务之前的所有 SQL 都已失效。业务请求号和状态条件保证重试幂等。

上线后观察死锁次数、事务时长、锁等待和受影响订单，并并发回放“回调 + 退款”相反时序。只把隔离级别调低，未必能解决记录锁顺序问题。