现代浏览器禁止直接重写alert()，因其被引擎绑定保护；需用Object.defineProperty劫持并转发调用，配合HTML/CSS/JS实现无障碍、非阻塞的自定义弹窗。
为什么不能直接“重写”alert()函数
浏览器禁止覆盖原生的 alert()、confirm()、prompt()，调用 window.alert = function(){} 在现代浏览器（Chrome 98+、Firefox 90+）中会被忽略，甚至触发 TypeError: Illegal invocation。这不是权限问题，而是 V8 和 SpiderMonkey 引擎对这些方法做了绑定保护——它们必须由浏览器内部以特定上下文调用，无法被用户代码劫持或替换。
所以“重写”不是覆盖函数，而是绕过它：拦截调用点，改用自定义 UI 替代。
如何在不改源码前提下全局拦截 alert()
适用于已有大量遗留代码（如老项目、第三方 SDK）频繁调用 alert()，又不想逐行修改的情况。核心思路是：在 JS 执行早期，用 Object.defineProperty 劫持 window.alert 的 getter/setter，把调用转发到你的实现。
- 必须在所有其他脚本执行前注入（例如放在
最顶部的<script></script>中） - 不能用简单赋值（
window.alert = myAlert），必须用defineProperty并设configurable: true - 需保存原始方法引用，但不能直接调用（会报错），要用
apply(null, args)或改用document.createElement模拟
const originalAlert = window.alert;
Object.defineProperty(window, 'alert', {
value: function(message) {
// 这里放你的自定义弹窗逻辑，例如：
showCustomModal({ type: 'alert', content: String(message) });
},
writable: false,
configurable: true // 关键：允许后续重新 define
});
用纯 HTML/CSS/JS 实现一个可替代的警告弹窗
不依赖框架，兼容 IE11+，重点解决原生 alert() 的硬伤：阻塞主线程、无法样式化、无法聚焦控制、键盘不可访问。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 结构上用
<div role="dialog" aria-modal="true"> 保证屏幕阅读器识别 <li>必须监听 <code>Escape键关闭，且首次打开时自动focus()到确认按钮 - 背景遮罩层要加
inert属性（或用pointer-events: none+ 临时移除 tabbable 元素）防止穿透点击 - 不要用
position: fixed+top: 50%做垂直居中——滚动页面时会错位，改用place-items: center或transform: translate(-50%, -50%)
最小可用示例：
function showCustomModal({ content }) {
const el = document.createElement('div');
el.innerHTML = `
<div class="modal-overlay" style="position:fixed;top:0;left:0;width:100%;height:100%;background:rgba(0,0,0,0.5);display:flex;align-items:center;justify-content:center;z-index:1000;">
<div class="modal-box" style="background:white;padding:1.5rem;border-radius:6px;box-shadow:0 4px 12px rgba(0,0,0,0.15);" role="dialog" aria-modal="true">
<p style="margin:0;font-size:1rem;line-height:1.5;">${content}</p>
<button id="modal-ok" style="margin-top:1rem;padding:.5rem 1rem;background:#007bff;color:white;border:none;border-radius:4px;cursor:pointer;">确定</button>
</div>
</div>
`;
document.body.appendChild(el);
const btn = el.querySelector('#modal-ok');
btn.addEventListener('click', () => document.body.removeChild(el));
btn.focus();
el.addEventListener('keydown', e => e.key === 'Escape' && document.body.removeChild(el));
}
要注意的兼容性与体验陷阱
看似简单的弹窗，实际在线上环境容易翻车：
- 移动端 Safari 对
focus()支持不稳定，按钮可能无法高亮；建议加tabindex="0"并用setTimeout(() => btn.focus(), 0) - 如果页面用了
font-display: swap，自定义弹窗文字可能闪动；确保字体加载完成后再触发，或用document.fonts.load() - 多个
alert()连续调用时，原生行为是排队阻塞，而 JS 是并发触发——你的弹窗会堆叠。需要加队列状态管理（isModalOpen标志位 + 数组缓存） - 某些 CMS 或广告 SDK 会动态插入 script 并直接调用
alert()，若你的劫持脚本加载晚于它们，就失效。必须确保它在内且无 defer/async
真正难的从来不是画个框，而是让它的行为和原生一样“可靠”——尤其是在各种加载时机、焦点流、无障碍要求混杂的真实页面里。
