@fml87 诶 太真实了。
每次问程序员 35 岁的问题，总有人说是月经贴、贩卖焦虑。没有人愿意正视这个问题，直到它真的发生了。

你就和室友直说 和他们住挺开心 但是觉得这样住太挤了 要找人事换宿舍 他们同学住人的是你不会说出去。

@documentzhangx66 兄弟做得太极端了，你和女友应该有更好的办法谈谈。没有人喜欢和易怒控制不住自己的人在一起的，亲人和家人也不会想。

目前不重要的存语雀，本地临时存图文用 one onte ，自己笔记存 github

确实容易陷入自我设限的陷阱中，比如觉得自己是后端，前端 /产品说的东西，就一概与我无关。
不是说要多为公司着想，主要是培养自己的思维和认知。

同理也适用某些产品。觉得自己是产品，就对技术一概不闻，觉得都是开发的事，自己不需要了解。

外包就是卖猪仔 卖到就是赚到

感慨下，真国企太香了

@zw1one 打错字。"可不是两种东西" -> "可是两种东西"

@hhjswf 国企子公司 /科技公司，和国企总部 /省公司。可不是两种东西[狗头]

### 不同用户的不同订单，是不会出现你说的问题的(你说的全局 synchronized 又是另外一个问题了)。这里我假设你要处理的问题是: 相同用户对一笔相同订单重复提交(多个用户来提交一笔订单也成立，扫码点餐)

- 场景 1: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回前，再用浏览器 A 发起支付
通常用前端校验，但前端校验可绕过。后台需要用"订单号 ID"加 redis 分布式锁校验，若不能获取到锁，则代表该订单有处理中且未返回的支付请求，拒绝该次请求。

- 场景 2: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回前，再用浏览器 B 发起支付
该情况前端无法校验。后台同样是 redis 锁处理。

- 场景 3: 用户用浏览器 A 登录，发起一笔支付，在支付结果返回后，再用浏览器 B 发起支付
该情况前端无法校验。后台通常在数据库表加上 data_version 字段处理，这里你用订单 flag 字段判断也可解决。

结论：
我没理解错的话，你这个问题是接口幂等问题。需要保证一个接口被多次调用(相同或不同客户端)得到的结果相同。
- 前端校验: 拦截部分客户端重复提交问题，但不能完全解决。
- redis 锁校验: 解决请求未处理完成，又出现新请求的情况。直接拒绝新请求。
- data_verison 校验(或者 flag 字段): 解决请求处理完成后，再次发起请求的情况。

### 至于异步回调，也是幂等问题。
如果你的支付申请处理好了，是不会出现两次回调的，除非第三方出问题了。
如果支付申请没处理好，出现两次回调，且订单 flag 都查到为 1 ，它们的操作都是修改订单结果为 2 ，代码运行两次是没有问题的。mysql 处理逻辑：先修改订单 flag 的事务 A 会给该条数据加写锁，事务 B 修改订单 flag 会等待获取锁。
出现这种情况把异步回调的日志记录好就行。

### 其他
- synchronized 无法处理一个应用部署多个副本的集群情况。可以按对象加锁。
- flag 字段，0 未支付，1 支付中，2 支付完成。
建议保留状态"支付中"，该状态可以表示等待第三方回调，当请求发出去，第三方出现问题(超时、宕机)没有回调的时候，便于排查问题。
- 做好上面这些。再来考虑异常退款给用户的人工操作。因为即使代码上处理了，还会有服务器宕机、第三方平台问题等情况出现。生产问题总归是少不了的 :)

老哥这么牛 好奇年包多少(不用太具体)

工作与自我学习不冲突，何况你在国企又不是在互联网。

写给 20 几岁的程序员：尽早考编上岸

骑驴找马 摸鱼刷题 摆烂等 N+1

先找找其他工作呗 不用在一棵树上吊死

脉脉看多了？想从体制内跳到互联网？

去三甲医院 别自己瞎几把吃药

话语权的问题 看你们领导 /公司给产品话语权还是给研发话语权 不过在普通公司研发都是最底层工具人

这还是只是看病，如果是住院陪护的话，也就会深深感受到家人的重要性。
家里人住院了，亲戚朋友最多就是过来看看，拿点水果坐一下，真正能一直陪在身边的只有家人。

在医院也看过陪护人与被陪护人由于病情压力、陪护压力等，进而情绪化崩溃，大吵大闹的。