原生 confirm() 因阻塞主线程、样式不可控、移动端体验差、async/await 中报错及被现代浏览器限制而基本不可用；应使用 Promise 封装的自定义弹窗，支持 await、无障碍聚焦、ESC 关闭、遮罩点击取消，并在 React 中通过 Hook 封装为受控组件。
浏览器原生的 confirm() 弹窗太丑、无法定制、阻塞主线程，还不能用在现代框架（如 React/Vue）的事件响应中——别用它。
为什么 confirm() 在实际项目里基本不可用
它会暂停 JavaScript 执行，导致页面卡死；样式完全不可控；移动端体验极差；在 async 函数或 Promise 链里直接报错（Uncaught (in promise) TypeError: Illegal invocation）。更重要的是，现代前端工程几乎都禁用了同步弹窗 API（比如 Chrome 对非用户手势触发的 confirm() 会静默忽略）。
用纯 HTML + CSS + JS 实现一个可 await 的确认弹窗
核心思路是：不阻塞线程，用 Promise 包装用户点击行为，返回布尔值模拟原生 confirm() 语义。弹窗结构必须脱离当前 DOM 上下文（推荐挂载到 document.body），避免样式污染和定位异常。
关键点：
立即学习“前端免费学习笔记（深入）”；
- 弹窗容器需设置
position: fixed和z-index，并监听ESC键关闭 - 点击遮罩层（
.modal-overlay）应等同于点击「取消」，但需排除对弹窗内容区的冒泡 - 返回 Promise 时，务必在用户点击后调用
resolve(true/false)，且确保只调用一次 - 弹窗 DOM 插入后要手动 focus 到第一个可交互元素（如「确定」按钮），满足无障碍要求
最小可用示例：
function showConfirm(message = '确定要执行此操作吗？') {
return new Promise((resolve) => {
const overlay = document.createElement('div');
overlay.className = 'modal-overlay';
overlay.innerHTML = `
<div class="modal-box">
<p class="modal-message">${message}</p>
<div class="modal-buttons">
<button type="button" class="btn-cancel">取消</button>
<button type="button" class="btn-confirm">确定</button>
</div>
</div>
`;
const handleCancel = () => {
document.body.removeChild(overlay);
resolve(false);
};
const handleConfirm = () => {
document.body.removeChild(overlay);
resolve(true);
};
overlay.querySelector('.btn-cancel').addEventListener('click', handleCancel);
overlay.querySelector('.btn-confirm').addEventListener('click', handleConfirm);
overlay.addEventListener('click', (e) => e.target === overlay && handleCancel());
overlay.addEventListener('keydown', (e) => e.key === 'Escape' && handleCancel());
document.body.appendChild(overlay);
overlay.querySelector('.btn-confirm').focus();
});
}
// 使用方式（支持 await）
// const ok = await showConfirm('删除后无法恢复，确认？');
在 React 中封装成 Hook 避免重复造轮子
直接操作 DOM 容易引发状态不同步，React 场景下建议用 useState + useEffect 控制显隐，并把 Promise resolve/reject 存在 ref 里供按钮回调使用。
注意这几点：
- 不要在组件内直接 return Promise —— 必须由外部调用方控制生命周期
- 弹窗组件需接收
onConfirm/onCancel回调，而非返回值；业务逻辑应放在回调里 - 若需支持「多个弹窗叠加」，得维护一个队列，但绝大多数场景只需单例（重复调用应覆盖前一个）
- CSS 动画需用
transition+opacity/transform，避免用display: none导致 ref 失效
容易被忽略的细节：焦点管理与键盘导航
很多手写弹窗没处理 TAB 键循环聚焦，导致键盘用户卡死在页面其他区域；也没拦截 ESC 或禁止背景滚动（body { overflow: hidden }）。更隐蔽的问题是：弹窗关闭后，焦点没回到触发按钮上，破坏操作流。
修复方式很具体：
- 弹窗打开时，记录
document.activeElement到 ref - 关闭后，调用
prevActive?.focus?.()（加可选链防报错） - 弹窗内所有可聚焦元素用
tabindex="0"显式声明，禁用tabindex="-1"以外的负值 - 遮罩层设
aria-modal="true"和role="dialog"，提升读屏器兼容性
这些不是“锦上添花”，而是上线前必须验证的可用性底线。否则 QA 或用户反馈的第一条就是：“键盘按不了确定”。
