重复请求防护 是什么意思

idempotency 这个词借自数学，意思是同一件事再做一遍也不会产生额外的结果。在网上购物的语境里，它指的是一种机制：重复发送同一条指令不会产生第二个结果。用买 eSIM 的人能懂的话说：如果你点付款时网络断了，于是又点了一次，具备这种防护的系统会认出这是同一个请求而不是新的请求，不会给你签发两份描述文件。

本页会讲清楚这套机制要解决什么问题、它依据什么原理、它能防和不能防的分别在哪里，以及你这边的哪些习惯能让它充分发挥作用。我们不会描述某一家商户的内部实现，因为各家不同，但下面的原理具有普遍适用性。

这套机制要解决的问题

你点了确认，手机信号顿了一下，屏幕停在转圈的图标上，然后提示连接失败。此刻你无法回答的问题是：你的指令到底有没有到达服务器。因为从你的角度看，请求根本没送到，和请求送到了但回复在返回途中丢失，这两种情况看起来完全一模一样。

这是网络通信的固有属性，把网速做得更快也消除不了。无论链路多快，总有一段时间回复正在路上、可能丢失。能改善的是让重试变得安全。如果重试不会产生新的结果，你就可以在不知道第一次是否成功的情况下放心重试，于是一个无法回答的问题变成了不需要回答的问题。

这套机制的基本原理

核心在于给每个请求一个身份。你开始结账时，系统会生成一个密钥，绑定到你这一次的购买意图上。这个密钥会随着同一个页面发出的每一个请求一起传送。当服务器收到带有它见过的密钥的请求时，它不会再做一遍，而是把第一次的结果返回给你。

有两个结果很重要。第一，无论你点多少次，最终得到的结果都是同一个。第二，你第二次点击得到的回答并不是新的回答，而是你在断网时错过的那个原始回答的副本。这正是你需要的，因为你想知道的是第一次的结果，而不是重新开始。

1. 1打开结账页面系统为这一次的购买意图生成一个请求身份。这个身份属于这个页面，而不属于你的整个账号，这就是为什么新打开的页面会被视为一次新的意图。
2. 2你第一次点确认请求带着这个身份发出去。如果一切顺利，回复会返回，事情到此结束。麻烦只在回复没能返回时才开始。
3. 3网络中断或页面卡住这时你无法知道另一端发生了什么。这是使用移动网络时的常态，尤其是在公共 Wi-Fi 或信号很弱的地方。
4. 4你再点一次同一个按钮第二个请求带着同样的身份，所以服务器知道这是同一个意图，而不是另一次购买。这正是这套机制发挥作用的时刻，也是在同一个按钮上重试比重新打开页面更安全的原因。
5. 5你得到一个结果系统返回第一次尝试的结果。如果那次成功了，你就会看到那个订单。如果它根本没到达，系统就把这次当作第一次来处理。无论哪种情况，你最后都只有一个订单。

为什么同一个按钮比重新结账更好

页面卡住时的本能反应是关掉它、从头来一遍干净的。这在普通表单上很管用，在付款环节却很糟糕。所谓从头来一遍，就是丢掉了那个请求身份，同时也丢掉了系统识别你已经表达过一次这个意图的能力。

因此，在同一个按钮上重试其实给了系统更多信息。它表示这是同一件事的第二次尝试；而重新打开结账页面表示这是一件新的事。系统无法替你猜测，因为真心想买两个套餐的人，操作是完全一样的。

可行的规则是这样的：当你不确定付款是否成功时，按顺序做两件事。第一，刷新同一个页面，或者再按一次同一个按钮。第二，如果仍然不清楚，就去看订单历史，而不是再买一次。订单历史是不需要猜测的事实来源，而且查看它不会产生任何东西。

在同一个地方浏览套餐并开始下单

这套机制防不了什么

重复请求防护是个很有力的工具，但它的适用范围比多数人以为的要窄。它只作用于带有同一身份的请求。这个边界之外的一切，在系统看来都是新的意图，会被照单执行。

• 重新打开结账页面并完成付款，永远是一个独立的订单。
• 从另一台设备或另一个浏览器购买，会被读作另一个意图。
• 在第一种付款方式看似失败后改用另一种，如果第一种随后成功，就可能留下两笔交易。
• 两个人为同一位旅客购买，系统无法识别成同一件事。
• 选错套餐这件事，和这套机制完全没有关系。

可能出现重复订单的迹象

大多数人是在账单寄来时才发现重复订单的，就安心程度而言，这已经太晚了。有好几个信号会出现得早得多，而且一分钟之内就能查完。

• 订单历史里出现两个前后相差几分钟、目的地相同的订单。
• 收到两封订单号不同的确认邮件。
• 银行 App 上列出两笔金额相同、时间相近的交易。
• 一趟行程却拿到两个不一样的二维码。
• 你刚重新买完，原来那个订单页面就开始显示成功。

如果发现这些迹象，先别急着把两份都装上。安装会让局面更难收拾。先弄清楚你要哪一份，另一份原封不动放着，等回复。没装的描述文件永远比已经装上的好处理。

已经出现重复订单，接下来怎么办

下面按先后顺序排列。要点是现在就把情况说清楚，而不是留到以后再解释。

1. 打开订单历史，把两个订单号都记下来。
2. 决定用哪一个，确认套餐与你的行程相符。
3. 只安装你选定的那一个，另一个不要动。
4. 把两个订单号都发给客服，并明确说明你用的是哪一个。
5. 在收到回复之前，先不要向银行发起任何流程，以免两个流程撞在一起。

不建议安装多出来那一份的原因是：一份已经安装并使用过的描述文件可能被视为已消耗，这会让撤销变得复杂得多。具体条款因套餐和供应商而异，我们不会替所有情形打包票，但原封不动放着始终是最稳妥的做法。

把两个订单号都发给我们

当你确实想要两份时

确实有不少情况是你本来就想要两份描述文件：一份给自己、一份给同行的人，或者两个套餐分别覆盖跨区域行程的两段。重复请求防护不会在这些情况下挡你的路，因为每一个意图都是从各自的页面开始的。

为了避免日后混淆，从购买时就把它们分清楚。一次只完成一笔，等第一笔确认后再开始第二笔；如果是帮别人买，请记下哪个订单号属于谁。一个二维码只能装在一部手机上，所以安装时弄混会把问题变得比它本来该有的更难解决。

从系统的角度看：为什么它不自动取消

一个合理的疑问是：系统看到相隔几分钟的两笔购买，为什么不直接取消第二个订单。答案是它无法知道你的意图。相隔几分钟买两次，对于帮全家人购买的人来说是完全正确的行为。自动取消会有毁掉真实订单的风险。

解决办法是分工。系统负责确保同一个请求不会被误执行两次；你负责确保新的意图确实是新的。当双方各尽其责，重复订单就会很少见，而真的出现时也能很快解决，因为记录清清楚楚。

付款环节的一些小习惯

系统这一侧的防护，在你的操作不与它作对时效果最好。下面这些习惯不是规定，但确实能明显降低出问题的概率，尤其是在信号不好的地方购买时，比如在列车上或机场里。

• 在稳定的 Wi-Fi 下购买，不要在移动途中信号断断续续时下单。
• 只开一个结账标签页，不要同时开好几个。
• 如果页面卡住，先等一会儿并刷新同一个页面，再做别的。
• 看到订单号就立刻记下来，它是之后所有沟通的钥匙。
• 再买一次之前一定先查订单历史，哪怕你确信第一次已经失败。

需要记住的要点

重复请求防护的存在，是为了让重试成为一个安全的动作。它解决的是靠速度解决不了的问题，也就是网络的不确定性。但它的作用范围止于带有同一身份的请求。任何在新页面上重新开始的操作都在它之外。

实际操作上要记住三点：按同一个按钮，而不是打开新页面；再买之前先查订单历史；如果确实出现两个订单，立刻把两个订单号都报过来，不要等账单。这三点几乎涵盖了结账环节会发生的所有情况。