退款到用户在网站的余额，退款前先把订单金额改为 0， commit 后再给用户加余额是不是就没有重复退款的风险了？还要考虑用户用多线程之类的手段重复退款吗？

这个流程跟一般会计准则很不相符，从经验来看非常有可能出问题。
订单信息不应该改动，最多是更新状态。订单应该是一个状态机，至于你是不是要加锁来实现稳定的状态变更，那么看你实际的需要

这样做有些反逻辑，修改金额为 0 本质上和修改状态为已退款有什么区别呢？

显然没解决问题，不还是有可能并发读订单金额？

在你判断“之前是否退款”的时候加锁。

数据库操作吗，加事务

新增负数金额的退单记录。

咋就不愿意加个分布式锁呢，你们并发有那么高吗

已经产生的订单不要去动它，创建一个新的以 id 为外键的退款表

数据库的问题数据库就可以解决，事务。

加锁呀...

楼上的大大们，我觉着 OP 能想出这个办法，也是花了不少功夫了。可能他并不知道数据库可以加锁，加事务。可以用别的组件加分布式的锁，等等。 总的来说，这个办法咋一看，还是可行的，就是并发高了感觉危险。

余额是动态每条记录 sum 出来的（可以缓存优化、可以定期归结上个月余额清除冗余记录），而不应该直接修改某个值。

退款操作对订单数据不能改。
增加一个退款表，关联订单 ID ，订单表订单状态字段增加退款中（中间态），已退款（完成态）。
操作时增加事务。和锁，可以使用数据库的悲观锁，毕竟简单就能实现。或者用 redis 锁，也就是分布式锁。
考虑多线程重复意思是防止用户并发请求是吧，能够防止这个的只有锁。事务是为了保证最终一致性。

最简单就是退款后台审核，一般很少有退款，如果有很多那更应该通过审核退款。

正常主要流程应该是：
1. 更改原订单状态
2. 拿到第 1 步成功值后，创建支付流水退款订单
3. 更新余额（和第 2 步在一个事务中处理）

需要设置多重保险，然后设置兜底的方案。

例如，可以从数据库表 scheme 上防范出现这种错误：

退款记录表中，需要有原订单编号 id 字段（且设置为 unique key ），如果产生重复的退款，因为 unique 的原因无法插入数据表中，因此不会出现重复退款增加金额的情况。

具体问题具体分析，多假设多测试才是王道。

订单金额改 0 后，改可以余额之前，服务 /服务器 /网络 炸了怎么办？

@cheng6563 #16 少退了能找客服处理，多退了估计没几个客户会找客服

加个退款表吧，订单表加状态，退款中，退款完成。
退款表，申请状态：待处理，同意退款，拒绝退款
退款状态：退款中，未到账，已到账
1.用户发起了退款申请，
1.1 不存在关联的待处理的退款单，那么订单进入退款中，新增一条待处理的退款数据…

手机码字不想写了，总的来说，以前我司订单中的退款中，只是一个业务流程，具体退款还要看退款表

等后台人员同意退款了，那么肯定是调用微信 /支付宝的退款接口，然后推荐表就是同意退款和退款中，

真正到账后，才更新已到账，同时订单也更新为退款完成。

当然以上不适用财务打款退款。