不能拦截alert/confirm/prompt，因其由浏览器直接控制、不抛异常、不触发事件，try-catch和window.onerror均无效；唯一可靠方案是全局覆盖或构建时禁用。
不能拦截。HTML 和 JavaScript 没有提供任何 API 可以捕获、阻止或重写 alert()、confirm()、prompt() 这类原生对话框——它们由浏览器直接控制，运行在 JS 执行上下文之外。
为什么 try-catch 或 window.onerror 都无效
这些对话框不是 JavaScript 异常，不抛出错误，也不走事件流。调用 alert("hi") 是同步阻塞行为，但既不返回 Promise，也不触发任何可监听的 DOM 事件或全局钩子。window.onerror 只捕获脚本执行错误；try-catch 只包裹 JS 运行时异常；两者对弹窗本身完全无感。
常见误判场景和真实现象
你可能观察到“警告没弹出来”，但这通常不是被“拦截”了，而是：
-
alert()被浏览器静默忽略：比如在非用户手势上下文（如setTimeout、fetch.then()、DOMContentLoaded）中调用，Chrome/Edge/Safari 直接跳过，不报错也不显示 - 移动端 Safari 或某些 WebView 主动禁用
alert()（尤其在 iframe 或 PWA 中），控制台也无提示 - 开发者工具里禁用了“JavaScript 弹窗”，手动勾选后才恢复——这不是代码问题，是调试设置
真正能做的只有替换，不是拦截
如果你的目标是“不让用户看到原生 alert()”，唯一可靠路径是：提前接管、彻底不用。
立即学习“前端免费学习笔记（深入）”；
- 全局覆盖：
window.alert = function() { console.warn("[blocked] alert() called with:", arguments); };—— 仅对后续调用生效，无法影响已压缩/内联的第三方脚本 - 构建时扫描：用 ESLint 规则
no-alert在 CI 阶段报错，从源头禁止提交 - 运行时降级：所有业务逻辑改用
<dialog></dialog>或 ARIArole="alert"横幅，它们可定制、无障碍、不阻塞脚本
注意：<dialog>.showModal()</dialog> 必须在用户点击等手势中调用，否则会报 Failed to execute 'showModal' on 'HTMLDialogElement' —— 这和 alert() 被静默忽略是同一类限制，只是表现不同。
第三方脚本里的 alert 怎么办
如果引入了不可控的第三方 SDK（比如某统计脚本偷偷调 alert()），你无法阻止它执行，但可以弱化影响：
- 在
最前注入覆盖：Object.defineProperty(window, 'alert', { value: () => {}, writable: false });（部分浏览器下有效，但非标准，且可能被eval绕过） - 用 Content Security Policy 的
script-src 'unsafe-eval'配合沙箱 iframe 隔离高风险脚本（复杂，成本高） - 接受现实：这类脚本本就不该进生产环境；优先推动上游修复，而非前端补漏
真正难的不是“怎么让它不弹”，而是“怎么确保所有路径都走不到 alert() 调用点”——这需要代码治理意识，而不是一个 patch 函数。
