不能完全可靠锁定支付流程，sessionStorage仅限当前标签页、需配合服务端幂等设计；应在点击支付时存带时间戳的锁标识，禁用按钮，并在跳转前或结果页清除，避免因页面关闭导致锁残留。
sessionStorage 能否可靠锁定支付流程？
不能完全依赖。它只在当前标签页有效，关掉页面或新开标签就失效；用户刷新页面后 sessionStorage 仍存在，但服务端状态可能已过期或被清空。它适合做「客户端轻量标记」，不是防重的最终防线，必须和服务端幂等设计配合。
怎么用 sessionStorage 标记「正在支付中」
在点击支付按钮时写入一个带时间戳的标识，同时禁用按钮；后续请求前检查该标识是否存在且未超时（比如 5 分钟）：
示例逻辑：
function startPayment() {
const lockKey = 'payment_lock';
const now = Date.now();
const expire = now + 5 * 60 * 1000; // 5分钟
<p>if (sessionStorage.getItem(lockKey)) {
const { timestamp } = JSON.parse(sessionStorage.getItem(lockKey));
if (now < timestamp + 5 <em> 60 </em> 1000) {
alert('支付请求已发出，请勿重复提交');
return false;
}
}</p><p>sessionStorage.setItem(lockKey, JSON.stringify({ timestamp: now }));
document.getElementById('pay-btn').disabled = true;
return true;
}- 务必用
JSON.stringify存对象，避免只存字符串导致无法扩展 - 不要只存布尔值（如
'true'），否则无法判断过期时间 - 按钮禁用只是体验层防护，不能替代接口幂等校验
为什么 sessionStorage.removeItem('payment_lock') 不能放在 success 回调里？
因为网络延迟、页面跳转、用户手动关闭窗口都可能导致 success 回调没执行。更稳妥的做法是：在支付成功跳转的回调页（比如支付宝/微信的 result 页面）里清除锁，或者在支付发起页加 beforeunload 监听做兜底清理：
兜底清理示例：
Browser Session Manager
下载
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
window.addEventListener('beforeunload', () => {
sessionStorage.removeItem('payment_lock');
});- 注意：
beforeunload在部分 iOS Safari 和 Android Chrome 中可能被忽略或限制执行 - 如果使用
window.location.href跳转到支付网关，跳转前可主动清除（但要确保跳转成功才清） - 推荐组合策略：跳转前清除 + 支付结果页再次清除
和 localStorage、cookie 比较有什么坑？sessionStorage 不跨标签页，所以用户开两个标签同时点支付，会各自生成锁 —— 这反而是优点，避免误锁其他操作；而 localStorage 共享，容易引发误判；cookie 需要后端参与、有大小限制、还涉及 HttpOnly 安全策略，不适合存这类临时客户端状态。
- 别用
localStorage 替代，它会让用户在另一个标签页无法发起新支付（即使前一个已失败）
- 不要把订单号、金额等敏感信息存进
sessionStorage，它可被前端脚本读取
- 服务端必须校验
X-Request-ID 或业务单号幂等性，sessionStorage 只是减少无效请求的「前置过滤器」
localStorage 替代，它会让用户在另一个标签页无法发起新支付（即使前一个已失败）sessionStorage，它可被前端脚本读取X-Request-ID 或业务单号幂等性，sessionStorage 只是减少无效请求的「前置过滤器」实际中最容易被忽略的是服务端没有做幂等控制，只靠前端锁住按钮，结果用户禁用 JS 或绕过按钮直接调接口，照样重复扣款。 sessionStorage 的价值在于降低正常用户的误操作概率，而不是代替服务端逻辑。
