表关系
退款订单可能包含多笔退款明细。即一对多的关系。
为什么会有多笔退款明细？
因为业务需要，而且代码也没有禁止只能有一笔明细。
具体原因看下文。
多笔退款明细产生的原因？
第一笔退款明细，发往渠道退款的时候，还没发往渠道，这个时候，就已经异常了。而且，状态也改变了，就不能自动重试。
那怎么办？怎么解决？
可以运营手工操作。具体原理见下文。
运营手工操作
解决方法1-不新创建明细
步骤
1.先重置状态
重置第一笔明细为可重试状态。
2.后重试
job自动重试。
注意：这种情况，是拿旧的退款明细，再次发往渠道退款。
运营是怎么操作的？
其实就是做了一个按钮操作，比如叫重试退款。这个按钮的功能，就是重置第一笔退款明细为可重试状态。
状态被修改之后，job就会自动重试，再次向渠道发起退款。
解决方法2-新创建明细
步骤
1.先把第一笔退款明细状态修改为失败；然后，再创建一笔新的退款明细
第一笔退款明细被修改为失败后，就是终态。
2.然后，job自动向渠道发起退款
job会自动拿新的退款明细发往渠道退款。
运营是怎么操作的？
就是提供了一个按钮操作，比如叫重新退款。这个按钮的功能，就是：先把第一笔退款明细状态修改为失败；然后，再创建一笔新的退款明细。
后面向渠道发起退款，job自动会干。
源码实现
1.可以直接复制旧的退款明细
因为大部分字段都一样。
2.然后，修改几个关键字段
1）序列号递增
退款订单号一样，但是，序列号不一样，序列号递增，表示当前是第几笔退款明细。和订单明细的序列号的作用一样。
退款订单号 + 序列号，组成唯一键。
2）发往渠道订单号
第一笔没有发往渠道订单号，因为发往之前就异常了。
和多笔订单明细的区别？
订单明细，是因为可以发往不同的渠道退款。
为什么可以？因为先微信支付失败，然后再用支付宝支付。
而，退款明细，只有一个渠道，并且是原路退款。但是，只要代码层面没有限制只能创建一笔退款明细，其实就可以创建多笔明细。而且，有的业务场景，确实是需要创建多笔退款明细。
但是，共同点是，都只有一笔明细成功。
优化
解决方法1
异常之后，代码自动回滚状态。而不是运营手工操作，而且运营不知道怎么操作就会经常找开发同事咨询怎么解决，浪费开发同事时间。
自动回滚状态之后，job就会自动重试。而不是运营手工重置退款订单状态。
解决方法2
表设计能不能简单一点？禁止多笔退款明细？
比如，刚才上面的解决办法1和解决方法2，其实解决的是同一个问题。如果只是这个问题，其实只需要解决方法1就够了，因为简单的东西更好理解。
但是，有其他的业务场景，确实需要用解决方法2去解决。所以，多笔退款明细是合理的。
