1923 字
5 分钟
《明日方舟:终末地》PayPal 盗刷事件

昨天刷到《明日方舟:终末地》海外测试 PayPal 盗刷的事,突然有一种看得有点难受的感觉,第一反应不是吃瓜,而是一种职业相关的条件反射————我太清楚这种事最后会怎么被讨论。

测试怎么没有测出来?

一、事故本质#

“随机扣到别人的钱包”这说明了订单与用户的绑定关系,在某一时刻是“非强一致”的

换句话说,后端有一瞬间不知道这笔钱该算谁的,这在任何涉及真实货币的系统里,都是不可接受的底线失守。

它可能来自于:

  • 订单与用户绑定的依据没有强唯一性和强隔离性
  • 并发状态下覆盖问题
  • 幂等机制未强化

总而言之:

系统在“不确定”的时候,没有停下来

二、从成因角度#

有可能发生的事:

TIP

只代表本人对于同类产品发生类似bug的可能成因猜测,不代表《明日方舟:终末地》事故真实成因.

  1. 流程视角

可能不是测试完全没测,更现实的可能是典型的高压上线链路

  • 海外版本首次大规模接入 PayPal
  • 公测时间已定、市场宣发已发
  • 第三方 SDK / 新支付方案上线窗口极短
  • 风控/支付压测:❌ 要么没跑,❌ 要么只跑了”理想路径”
  • 测试或安全曾提出风险,但被”概率不大""PayPal 本身很成熟""先上,出事再关”驳回

然后真的翻车了

  1. 设计视角

以订单 ID 设计为例,常见风险包括:

  1. 并发碰撞(时间戳不足以保证唯一)
  2. 分布式时钟漂移(NTP回拨导致时间倒退)
  3. 缺少机器号或序列控制
  4. 唯一性未加数据库强约束

但必须客观讲:

单一设计缺陷,通常不足以直接导致“扣错人”。

真正危险的是组合问题,例如:

  • ID 冲突 + 回调匹配只依赖 order_id
  • 回调未校验 user_id 强绑定
  • 幂等机制仅基于“是否已完成”判断
  • 异步通知乱序未处理

当这些因素叠加在高并发场景下,系统就可能出现:

  • 订单覆盖
  • 错单匹配
  • 状态提前更新
  • 重复回调误判

支付事故往往不是“一个 bug”,而是一条链路上多个“理论上概率不高”的缺陷叠加。

  1. 经验视角

这个猜测无法验证,但它揭示了一个典型陷阱:国内团队习惯微信、支付宝的”兜底”模式,容易低估海外支付的复杂性。PayPal不会帮你处理幂等、保证时序、不为你的并发bug买单,它是一个raw的金融接口。如果心智模型停留在”接SDK”,而实际面对的是”对接金融系统”,认知落差本身就是风险。

三、这种事情容易测出来吗?#

理解了可能的技术根因,再说句得罪人的话:这种级别的支付事故,常规测试流程本来就不是为它设计的。

我们日常的测试环境是高度受控的:

  • 网络是稳定的内网
  • 第三方支付是沙箱环境
  • 并发是脚本模拟的,不是真实的人类行为
  • 回调是顺序的、可预测的、不会乱序重试的

但真实的PayPal接入是什么场景?

  • 全球多地区玩家同时涌入
  • 真实的网络延迟和丢包
  • PayPal服务器的异步回调可能延迟、重复、乱序到达
  • 玩家行为不可预测(连点、取消、快速切换账号)

在测试环境里复现”用户A付款,用户B被扣,一般的测试方法确实难以覆盖这样的异常情况”

这除了测试人员的能力问题,也涉及到测试方法论的天花板,需要有相当的线上经验的测试人员去给出相关的测试方案

四、真正该问的不是”怎么测”,而是”敢不敢上”#

既然测不全,那该怎么办?

答案是:把”测不全”本身当成一个风险信号,而不是一个可以忽略的技术限制。

当测试无法给出”安全”的结论时,正确的做法不是假装安全,而是建立防御性机制: 上线限额、实时熔断、一键关闭开关、明确的回滚预案。这些不是”过度设计”,是对不可知风险的敬畏

五、QA的价值:从”找bug的人”到”踩刹车的人”#

初级QA关注”对不对”: 功能是否符合文档?流程能否跑通?成熟QA关注”敢不敢”: 失效代价是什么?哪些风险测试无法覆盖?证据不足时,默认该走还是该停?

如果QA能在评审阶段提出:“基于现有条件,我无法确认支付系统在极端并发下的稳定性。建议上线时启用限额保护,并准备熔断方案。“——这不会改变技术实现,但会改变决策语境,让”上线”从默认动作变成有条件、有兜底的决策

QA的专业尊严,不在于能测出多少bug,而在于能否在证据不足时,阻止一场赌博。

六、学到了什么#

需求评审阶段: 把支付模块标记为P0风险,要求必须配备熔断和回滚方案才能上线

测试执行阶段: 测试报告里不写”支付功能测试通过”,而是写”基础流程验证通过,高并发/异常回调场景存在不可覆盖风险”

上线评审阶段: 如果风控方案不到位,明确投反对票——哪怕被否决,也要留下记录,让决策者意识到自己在冒险

事故发生后: 不参与”谁的责任”的争论,专注于回答”系统当时处于什么状态”。推动建立支付模块的专项评审机制,把教训转化为制度性约束

高速行驶的列车上,所有人都在兴奋地讨论前方风景,只有一个人盯着仪表盘,计算着如果此刻刹车,还需要多远才能停下。

那个人可能很扫兴,可能不被理解,可能在99%的情况下都显得多余。

QA就是那个应该离刹车最近的人

这次事件最让我共鸣的,是一种熟悉的无力感——你看到了风险,但你没有站在能阻止它的位置上。

我希望下一次,我们都能离那个刹车手柄再近一点点。哪怕最后还是没有拉住,至少我们知道自己该站在哪里。

分享

如果这篇文章对你有帮助,欢迎分享给更多人!

《明日方舟:终末地》PayPal 盗刷事件
http://wangxvvv.top/posts/zmd/
作者
王诩
发布于
2026-01-23
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时