seasonsolt

用 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：你按重量买就按重量权重去均摊啊，加权平均 百度了解一下

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

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