Stripe重复创建PaymentIntent时幂等键应绑定购物车或会话标识
在应用数据模型中，幂等键应当绑定在你为购物车或客户会话分配的标识上，而不是绑定在PaymentIntent对象本身。Stripe文档的表述是，这个键通常基于你在应用内关联购物车或客户会话的那个ID。这样做的目的很单纯：同一笔购买在重试或并发请求下不会生成多个PaymentIntent。
幂等键防的是什么
需要防的是“同一笔购买被创建成多个PaymentIntent”这一类重复。支付流程中，客户端可能因为网络重试、页面刷新或用户重复点击而再次发起创建请求；如果每次请求都生成新的PaymentIntent，同一购物车就会对应多个支付对象，后续的状态跟踪和失败重试都会变得混乱。幂等键的作用是让这些重复请求被识别为同一件事，从而只保留一个创建结果。
这里要区分两件事：幂等键防的是“重复创建”，不是“重复扣款”的全部机制。文档只说明该键用于防止为同一笔购买创建重复的PaymentIntent，不涉及幂等键的有效期，也没有给出具体实现代码。因此不能把幂等键当成覆盖支付全流程的通用去重手段。
为什么绑定在购物车或会话上
文档给出的理由与对象状态的用途有关：复用同一个PaymentIntent的好处在于，对象状态可以帮助跟踪某个购物车或会话下失败的支付尝试。也就是说，PaymentIntent在应用里的检索入口是购物车或会话，而不是反过来。
如果幂等键绑定在PaymentIntent上，逻辑上会陷入循环：幂等键本应用来避免创建出第二个PaymentIntent，却要依赖已经创建出的对象来定位。绑定在购物车或会话ID上则没有这个问题——请求先带着应用侧的标识到达，服务端据此判断这是不是同一笔购买，再决定是否复用已有对象。
文档同时提到，可以在应用的数据模型中把PaymentIntent的ID存放在客户的购物车或会话上，方便后续检索。这与幂等键的绑定对象是两件事：前者是创建之后如何找回对象，后者是创建之时如何避免重复。两者都指向同一个应用侧标识，但作用阶段不同。
一个可复算的假设示例
以下标识与请求次数均为说明用途的假设，不是通用公式。
假设某应用为每个购物车分配一个标识，形如cart1001。用户在一次结账中先后触发三次创建请求，三次都携带同一个幂等键，该键由cart1001派生。按幂等键的用途，这三次请求对应同一笔购买，只应产生一个PaymentIntent；应用随后把这个PaymentIntent的ID写回cart_1001对应的记录。若第二次请求因超时重发，仍然不会多出一个对象。
反过来，如果三次请求各自使用不同的键，例如按请求序号生成，那么它们会被视为三笔不同的购买，可能产生三个PaymentIntent。这个对比说明键的取值来源决定了去重边界：边界应当落在“一笔购买”上，而应用内最能代表一笔购买的标识就是购物车或会话。
边界与不要延伸的部分
文档没有说明幂等键的有效期，因此不能推断“过期后重试一定安全”或“永不过期”。文档也没有给出具体实现代码，所以不应把键的生成方式写成某种固定算法。可以确定的只有用途与绑定对象：键通常基于应用内购物车或会话ID，仅用于防止重复创建PaymentIntent。
另外，client secret是PaymentIntent自身的唯一密钥，用于客户端完成支付流程，它与幂等键不是同一类东西。把client secret当作幂等键使用，或者反过来，都超出了文档支持的范围。需要传递client secret时，它是从服务端端点取回后交给客户端使用的，这与创建阶段用幂等键去重属于不同环节。
落地时的判断顺序
在写创建逻辑前，先确认应用里“一笔购买”对应哪个标识：是购物车ID还是客户会话ID。把这个标识作为幂等键的取值基础，并在创建成功后把返回的PaymentIntent ID存回同一记录，供后续检索和失败重试跟踪。不要在每次请求时新生成一个与购买无关的随机键，否则去重边界会落到请求层面，而不是购买层面。