连弹三次是因未节流导致多次点击触发多次alert：用时间戳防抖（200ms内重复触发忽略）最轻量可靠，无需库且兼容性好。
click 事件里直接调用 alert() 为什么连弹三次？
这不是 bug，是浏览器对同步阻塞行为的自然反应：用户快速点击按钮时，alert() 没法中断 JS 执行流，每次 click 都会走到 alert() 调用，结果就是点几下弹几下。尤其在表单提交、删除确认等场景，用户手抖一下就触发多次警告，体验极差。
根本问题在于没做节流——你不是要“阻止弹窗”，而是要“让多次点击只产生一次有效响应”。
- 别用
setTimeout包一层就完事：它不解决并发触发，只是延迟执行，仍可能叠加弹出 - 别依赖
document.activeElement判断焦点：alert 弹出后焦点自动丢失，判断失效 - 禁用按钮能缓解但不治本：如果警告是独立于按钮逻辑（比如全局错误捕获触发），禁用按钮完全无效
用时间戳防抖是最轻量可靠的方案
在触发 alert() 前加一个简单的时间窗口判断，200ms 内重复触发直接忽略。不需要引入任何库，兼容所有浏览器，且不影响可访问性（screen reader 不会读 alert 多次）。
示例代码：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
let lastAlertTime = 0;
function showAlert(message) {
const now = Date.now();
if (now - lastAlertTime < 200) return;
lastAlertTime = now;
alert(message);
}
<p>// 绑定到按钮
document.getElementById('deleteBtn').addEventListener('click', () => {
showAlert('确定要删除？此操作不可撤销');
});
- 阈值设为 150–300ms 足够覆盖误触，又不会影响正常连续操作（比如快速切换 tab 后再点）
- 变量
lastAlertTime必须定义在函数外或闭包内，否则每次调用都重置 - 不要用
setTimeout+clearTimeout模拟防抖：alert 是同步阻塞，clearTimeout 在 alert 返回后才执行，起不到过滤作用
confirm() 和自定义弹窗也要防抖，但逻辑不同
confirm() 和基于 div 的模态弹窗虽然不阻塞 JS，但用户仍可能在弹窗未关闭前疯狂点击触发源按钮，导致多个弹窗层叠或逻辑错乱。
- 对
confirm()：同样用时间戳防抖，但需注意它返回true/false，防抖后不能丢掉这个返回值语义 - 对自定义弹窗：必须在弹出前检查是否已存在实例（比如用
document.querySelector('.modal.show')），而不是只靠时间戳——因为用户可能手动关掉一个再点另一个 - 关键区别：
alert()和confirm()是浏览器原生模态，无法用 CSS 或 JS 中断；而自定义弹窗可以主动销毁/隐藏，所以更适合加状态锁（如isModalOpen = true）
真正容易被忽略的是副作用清理
防抖只管“不重复弹”，但不管“弹了之后怎么办”。比如你在 alert() 后紧接着发请求或跳转，而用户在弹窗期间又点了别的按钮，就可能造成状态混乱。
务必检查：
- 是否在
alert()调用后立即设置了一个临时锁（如isAlerting = true），并在用户关闭后重置？否则防抖失效 - 是否把业务逻辑（如删除 API 调用）放在
alert()之后？应改用confirm()或 Promise 化弹窗，确保用户明确确认后再执行 - 移动端要注意：iOS Safari 对
alert()的处理更严格，连续调用可能被静默丢弃，时间戳防抖在这里反而更稳定
