无登录场景下如何防止用户重复创建未支付订单？

核心方案的可行性 #

你的思路是完全可行的，核心逻辑是利用session token作为匿名用户的唯一标识，具体落地可以按以下流程执行：

• 用户首次创建订单时，复用当前会话的session token（若不存在则生成），将其与未支付订单绑定后存入数据库
• 用户再次发起订单创建请求时，先通过session token查询数据库：
  • 若存在未支付状态的关联订单，直接跳转至该订单的支付页面，不再生成新订单
  • 若不存在未支付订单（或已有订单已完成/超时失效），再创建新订单并绑定当前session token
• 订单完成支付或超时失效后，无需删除session token，只需将订单状态标记为「已完成」或「已失效」即可——session本身自带过期机制，后续会话过期后用户会被视为新访客

落地时需注意的细节 #

• Session有效期配置：建议将session过期时间与支付平台的订单有效期对齐（比如2小时），或设置为24小时。session过期后用户再次访问会生成新会话，此时允许创建新订单，符合用户长时间未操作的场景逻辑
• 未支付订单的定时清理：即使有session标识，仍需后台定时清理超过支付有效期的未支付订单，避免数据库冗余数据堆积
• 集群环境下的Session共享：如果部署多台服务器，不能用服务器内存存储session，需改用Redis等分布式存储来共享session，否则用户切换节点时会被识别为新用户，导致重复创建订单
• 支付回调异常处理：需通过定时任务主动查询支付平台的订单状态，避免因回调丢失导致本地订单状态未更新，进而让用户误以为仍有未支付订单

补充优化思路 #

如果session方案存在集群部署的顾虑，可结合浏览器本地存储做辅助校验：

• 用户创建订单后，将订单ID存入浏览器的localStorage
• 用户再次发起创建请求时，先读取localStorage中的订单ID，查询该订单状态：
  • 若仍为未支付状态，直接跳转至对应支付页
  • 否则清除localStorage中的订单ID，再创建新订单
• 这种双重校验的方式，能进一步降低重复订单的生成概率

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