我的 0125 也不能正确回答，可能楼主没有情况上下文重新提问吧。但是把 “the error” 更换成 “the java.lang.Error”...哪怕 3.5 回答的也很好，所以无论是实验设置，还是实验结论我都不是很认可

追完了所有楼层，有些感触，自己工作 10 年或多或少都有类似的经历，只是结果不尽一样，此类问题我愿称之为“向上管理”，我在这个 up 主(B 站：产品老曾)学习了很多向上管理的技巧，祝楼主下份工作一切顺利吧。

我最近有一个观点，那就是 Java 后端的成长曲线非常不友好，S 曲线只是理想情况，大部分都是一个抛物线。在你刚成为熟手的时候就被迫参与了公司管理工作，压榨了你成长学习的空间，将自己能力高度与平台(公司)绑定，一旦换工作就是降职降薪，再结合上经济大环境和年龄歧视，使得下降曲线更加陡峭。

有大型互联网公司支付后端全链路工作经验，有海外支付创业经验，有强烈日语学习兴趣和计划，但是 600w...

用 karabiner 了？ 升级到最新版试试，我已经完全解决了，毕竟 java 程序员一点要点几百次 command + 触摸板轻触 来跳转函数实现，我很确定我自己的 mbp 14 是没有了。
顺带说一下，macOS 12.3

@Chinsung 第三个问题确实是存在的，如果恰好退款时间恰好跨清算批次了，处理起来自然是恶心的，但是概率应该很小吧。 然后是纯技术的，lock free 更多算是一种技术洁癖吧，不一定能有多大性能损失，毕竟不是每一家都能做到 jd 、tb 的量级的。

@Chinsung 你的疑问全部理解，其实这个帖子里的我所谓的“不那么高质量”方案，我们都经历过，或者说这个行业都经历过，敢妄评“优劣”自然是建立无数的实践和采坑的基础之上的。 实践远比我的回答有意义，你可以去测试一些非 sdk 支付场景，支付成功后立马断网（飞行模式），或者杀掉支付 app ，切进程到商户收营台 再次支付。有些平台可以正常支付，但是很快自动退款，还有戏平台，会弹出报错 “您当前订单正在支付中,balabala.......” 。最后，做个统计，是不是实力更强的平台选择了 自动退款方案，比如 麦当劳、KFC...然后锁定单是不是相对弱一些（除了滴滴打车）

@documentzhangx66 本帖唯一高质量回答，和我们现在的处理方式比较接近，分布式 & lock free
1：首先订单系统根据用户请求做了 event 分发降低了并发量，数据库设计面向 event sourcing ，只增量记录 event log 2：重复支付发生时，订单实收 > 应收，追述到支付事件的 event log ，拿到支付凭证发起退款就可以了。 3：无论是前端锁还是后端锁，用户支付体验都会受影响，而且影响系统吞吐量

RTS/MOBA 游戏 更多不是看平均帧数，而是看帧数波动，从这个角度来看，m1 max 几乎不可玩 dota2

m1 max 32 GPU: 不怎么样，虽然平均帧数不低，但是抖动厉害，关键时候卡一下， 跳大 就变成 大跳 了，然后被队友疯狂打赏。

@markgor 1：小数点用尾差法，这个不是问题，saas/erp 行业都这么玩 2：可以百度下 “淘宝双 11 退款规则”，老生常谈了 3：你按重量买就按重量权重去均摊啊，加权平均 百度了解一下

真难用，回车换行会自动提交...把运费均摊到商品上，算出一个商品成交价格，用商品成交格来退款就好了。不是什么难的事情，甚至还可以支持按照 价格 /重量 /体积 等各维度均摊其他费用到商品上。

不小心点回车提交了，补充一下

还是我的订单的退款逻辑好，其实很简单

和楼主遭遇几乎一样，每天重启 2 次了
不过现在基本解决了，方法如下:
1：打开”活动监视器“，找到 非 Apple silicon 的应用（种类 = intel ），一一寻找对应的原生 Apple silicon 版本替换。
2：我个人替换了 iterm2 ，istat, intelliJ 全家桶，wechat 开发工具，搜狗输入法，karabiner ，btterZip ，postman, jdk 等等...
3：时间有限，没有逐一排除变量验证，总之目前仅只有“企业微信”一个 x86 程序
4：从结果来看，已经 2 周没有重启、死机过了