alert()虽同步阻塞JS线程，但不阻止用户再次点击按钮，导致多个点击事件排队执行、重复提交；根本解法是在事件入口禁用按钮并确保finally恢复，同时服务端必须做幂等校验。
点击按钮后弹出 alert() 为什么挡不住重复提交
因为 alert() 是同步阻塞的，但只阻塞当前 JS 执行线程，不阻止用户再次点击按钮——浏览器在弹窗期间仍会响应新的点击事件，等用户点“确定”后，多个点击事件排队执行，fetch 或 XMLHttpRequest 就发出去好几遍。
常见现象：点一次按钮，后台收到 2–5 次相同请求；日志里看到连续几条几乎同秒的插入记录；表单提交后页面卡顿或报错 409 Conflict。
- 根本原因不是弹窗本身，而是没在事件触发入口做防抖/禁用/标记
-
alert()已被现代项目普遍弃用，但它暴露出的并发控制缺失问题依然高频存在 - 即使换成
confirm()或自定义 Modal，只要没同步禁用按钮或拦截后续 click，问题照旧
最简可靠的按钮级防重：禁用 + 恢复
在事件处理函数开头禁用按钮，请求结束（无论成功失败）再恢复。这是兼容性最好、逻辑最直白的方案。
关键点：
立即学习“前端免费学习笔记（深入）”；
htmlppt.skill
下载
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 必须在
try外或finally块中恢复按钮，否则请求抛错或网络中断会导致按钮永久禁用 - 禁用前保存原始
textContent或value，避免恢复时文本错乱 - 不要只靠 CSS 类（如
.disabled）模拟禁用，必须设button.disabled = true，否则仍可触发click
const btn = document.getElementById('submit-btn');
btn.addEventListener('click', async () => {
const originalText = btn.textContent;
btn.disabled = true;
btn.textContent = '提交中...';
try {
await fetch('/api/order', { method: 'POST' });
alert('提交成功');
} catch (err) {
alert('提交失败：' + err.message);
} finally {
btn.disabled = false;
btn.textContent = originalText;
}
});
需要支持多次操作时：用 loading 状态 + 请求标识
比如“删除多项”“批量导出”，用户可能连续点不同行的按钮。这时不能全局禁用整个按钮组，得为每个操作单独标记。
做法是给每个触发元素打唯一请求 ID（如时间戳+索引），缓存到 Map 或对象里，发起前检查是否已在进行中。
- 适合场景：列表页每行一个操作按钮、卡片式交互、Tab 切换下的独立提交
- 注意清除时机：成功后立即删 ID；失败后也建议删（除非业务要求“失败后禁止重试”）
- 避免用
setTimeout清理 ID，应以请求生命周期为准，否则可能清理过早或遗漏
const pendingRequests = new Map();
function handleDelete(itemId) {
const reqId = `delete-${itemId}-${Date.now()}`;
if (pendingRequests.has(reqId)) return;
pendingRequests.set(reqId, true);
fetch(`/api/item/${itemId}`, { method: 'DELETE' })
.finally(() => pendingRequests.delete(reqId));
}
服务端兜底为什么不能省
前端防重只是体验优化，绝不能替代服务端幂等校验。用户可以绕过 JS（禁用脚本、curl 直发、重放请求），所以关键接口必须有服务端防护。
典型手段：
- 对创建类接口，用
idempotency-key请求头 + Redis 过期缓存判重（5 分钟内相同 key 只处理一次） - 对更新类接口，带版本号（
If-Match）或时间戳比对，避免覆盖写 - 数据库层加唯一约束（如订单号唯一），让重复请求直接报
409而非静默成功
前端防重和服务端幂等是两层独立防线，少一层都会导致数据异常。尤其在金融、库存、下单等场景，漏掉服务端校验等于裸奔。
