前端页面刷新场景下的幂等性处理方案咨询

问题背景 #

后端已完成Idempotency Key的处理、查询与存储，React前端当前在用户点击「创建订单」按钮时通过uuid()生成该密钥，但存在页面刷新后生成新密钥的问题：例如订单已创建但请求超时，用户刷新页面重试时，无法复用原密钥，可能导致重复创建订单。

已考虑的方案 #

• 将Idempotency Key与isProcessed布尔标识、时间戳存入localStorage：判断请求未处理则复用，否则重新生成，但存在localStorage/缓存被清除的风险。
• 在Apollo/Axios中添加拦截器实现同密钥重试：仅能处理页面未刷新时的重试，无法解决页面刷新后的问题。

补充可行方案 #

1. 关联临时订单草稿ID #

在用户进入订单创建页时，先向后端请求一个临时订单草稿ID，后端将该ID与Idempotency Key绑定存储。页面刷新后，前端先请求后端获取该草稿ID对应的Idempotency Key：

• 若密钥存在且对应请求未处理，则直接复用；
• 若不存在或已处理，则生成新密钥并关联新的草稿ID。
• 优势：密钥存储在后端，不受前端缓存清理影响；草稿ID可同步关联订单预填信息，提升用户体验。
• 注意：后端需为草稿ID设置合理过期时间（如24小时），避免无效数据堆积。

2. URL参数传递幂等键 #

用户点击「创建订单」生成Idempotency Key后，将其作为查询参数追加到当前页面URL（示例：/create-order?idempotency-key=xxx）：

• 页面刷新时，从URL中读取该密钥，调用后端接口校验其状态；
• 若密钥有效（对应请求未处理）则复用，否则重新生成新密钥并更新URL参数。
• 优势：无需依赖前端存储，刷新后直接从URL获取；用户可复制链接在同会话下的其他标签页重试（需后端结合用户身份校验合法性）。
• 注意：后端需结合用户身份、请求内容做权限校验，避免密钥被恶意利用；确保URL参数无敏感信息。

3. SessionStorage+后端兜底校验 #

优先将Idempotency Key、请求状态存入SessionStorage（仅当前会话有效，关闭标签页自动清除，更贴合订单创建的单次会话场景）：

1. 点击创建订单时生成密钥，存入SessionStorage并标记状态为「处理中」；
2. 请求成功/失败（确定订单状态）后，更新状态为「已完成」或「失败」；
3. 页面刷新后，先从SessionStorage读取密钥，调用后端校验状态：未处理则复用，已处理则生成新密钥；若SessionStorage无数据，直接请求后端查询当前用户最近的未完成订单请求密钥。

• 优势：兼顾前端快速读取和后端兜底，降低前端存储失效的影响；SessionStorage生命周期更匹配订单创建流程。

4. 后端生成并关联用户会话 #

由后端负责生成Idempotency Key，替代前端生成逻辑：

1. 首次发起创建订单请求时，后端生成密钥并返回给前端，前端存储该密钥；
2. 页面刷新后，前端先从存储读取密钥，若不存在则请求后端，通过用户会话（如Cookie中的SessionID）查询当前用户未处理的订单请求对应的密钥；
3. 若后端查询到有效密钥则复用，否则生成新密钥。

• 优势：后端掌控密钥全生命周期，一致性更高；结合用户会话可快速定位未完成请求。
• 注意：后端需维护用户会话与密钥的关联关系，并设置合理过期时间，避免会话过期后无法复用。

内容的提问来源于stack exchange，提问作者matrix