confirm()仅在用户主动触发的同步点击事件中有效，异步调用会被浏览器拦截；需改用自定义模态框实现可本地化按钮、焦点管理、防重提交及移动端适配。
点击按钮后弹出确认框，但 confirm() 没反应或被拦截
浏览器对非用户主动触发的 confirm() 调用会静默屏蔽——比如在异步回调（setTimeout、fetch.then）、事件委托未绑定到真实触发元素、或 Vue/React 的响应式更新钩子中直接调用，都会失效。
实操建议：
- 确保
confirm()仅出现在原生onclick属性、addEventListener('click', ...)回调、或 React 的onClick处理函数最顶层（不嵌套在 Promise.then 或 useEffect 异步逻辑里） - 不要在
onload、DOMContentLoaded等页面加载时机自动弹窗，用户没发起操作，浏览器必拦 - 若必须异步判断后再确认（如先校验权限），改用自定义模态框，而非依赖原生
confirm()
需要带「取消」和「确定」文字，且支持中文，但 confirm() 无法自定义按钮文本
confirm() 是浏览器原生 API，按钮文案完全由系统语言决定，无法修改。想控制「确定」「取消」的显示文字、样式或添加「不再提示」复选框，必须手写 HTML + CSS + JS 模态层。
实操建议：
- 用一个
<div id="confirm-modal" class="modal"> 包裹标题、正文、两个 <code><button></button>（分别加data-action="confirm"和data-action="cancel"） - 通过
element.classList.toggle('show')控制显隐，避免用display: none导致焦点丢失；务必用focus()主动聚焦「确定」按钮 - 点击遮罩层（
.modal-overlay）或按Escape键应等同于点「取消」，需监听keydown并过滤event.key === 'Escape' - 所有副作用操作（
location.href=...、form.submit()、fetch(...)）必须严格包裹在if (confirmed)块内 - 自定义模态框中，绑定「确定」按钮的
click事件时，记得在回调末尾加modal.close()或移除类名，否则用户可能重复点击 - 如果确认逻辑涉及防重提交，建议在弹窗出现瞬间就禁用原按钮（
btn.disabled = true），并在「取消」后恢复，避免用户狂点 - 模态框容器加
top: 50%; left: 50%; transform: translate(-50%, -50%)，比top: 0; margin: auto更可靠 - 按钮至少设
min-width: 88px; min-height: 44px; padding: 12px 20px，并用@media (hover: none) and (pointer: coarse)针对触控设备微调 - 禁止给模态框父容器设
overflow: hidden，否则 iOS Safari 可能裁掉阴影或遮罩层边缘
点击「确定」后页面跳转或提交表单，但用户点了「取消」却仍执行了操作
常见错误是把关键逻辑写在确认弹窗调用之后，而不是放在确认返回 true 的分支里。例如：if (confirm('删除？')) { del(); } else { console.log('已取消'); } 写成了 confirm('删除？'); del(); —— 后者不管用户点什么都执行。
实操建议：
移动端 Safari 上确认框位置偏移、文字截断或触摸区域过小
iOS Safari 对 position: fixed 和 transform 的渲染有兼容性问题，尤其在横屏切换或键盘弹出后，可能导致模态框错位；同时默认按钮尺寸太小，不符合 WCAG 触摸最小 44×44px 要求。
实操建议：
自定义确认框不是“做个弹窗”就完事，核心在于阻断默认流程、接管用户意图、并确保每一步反馈都可预期。最容易被忽略的是：没有处理 Tab 键焦点循环，以及没在「取消」后恢复原始 UI 状态（比如开关按钮的 disabled 状态、输入框的 readonly 属性）。这些细节不补全，用户会觉得“点了没反应”或“点错了收不回来”。
