最简写法是onclick="if (!confirm('确定要删除？')) return false;"，它直接阻塞执行并阻止默认行为；需避免仅写onclick="confirm('...')"导致取消后仍执行；移动端兼容性差，推荐用dialog或Sweetalert2替代。
点击按钮触发 confirm 弹窗的最简写法
直接在 <button> 上用 onclick 调用 confirm()，是最快速生效的方式。它不依赖外部 JS 文件或框架，适合临时验证、表单提交前拦截等轻量场景。
常见错误是把 confirm() 当作纯提示——它其实会阻塞后续执行，并返回布尔值，必须显式处理返回结果，否则点击“取消”也会继续执行。
-
onclick="if (!confirm('确定要删除？')) return false;"：推荐写法，取消时中止默认行为（如表单提交） - 避免只写
onclick="confirm('...')"：弹窗点了“取消”后，代码仍往下走 - 如果按钮是
<input type="submit">，return false才能阻止表单提交；<button>默认不提交，但加了type="submit"后同理
用 addEventListener 绑定 confirm 的标准做法
当页面有多个按钮、或需要复用逻辑时，用 addEventListener 更可控。它和内联 onclick 的核心区别在于：事件监听器里可以访问 event 对象，方便做 event.preventDefault() 精准拦截。
容易忽略的是：如果按钮本身会触发跳转（比如 <a> 或带 formaction 的按钮），仅靠 confirm() 返回值不够，必须调用 event.preventDefault() 阻断默认动作。
立即学习“前端免费学习笔记（深入）”；
- 给按钮加
id="deleteBtn"，然后在<script>中写：document.getElementById('deleteBtn').addEventListener('click', function(e) { if (!confirm('此操作不可撤销，确定吗？')) { e.preventDefault(); } }); - 不要在监听器里直接写
confirm()后跟业务逻辑——若用户点“取消”，业务逻辑仍会执行，必须用if包裹 - 现代写法可配合箭头函数，但注意
this指向变化；需访问元素属性时建议用e.target
confirm 在移动端和 Safari 上的兼容性问题
confirm() 全浏览器支持，但实际体验差异大：iOS Safari 会强制暂停页面滚动、遮罩层无法自定义、且在 PWA 或某些 WebView 中可能被系统拦截或静默失败。
这不是 bug，而是平台策略——苹果限制非系统级弹窗干扰用户，尤其在全屏模式下。所以别指望靠 CSS 覆盖 confirm 样式，也别在 iOS 微信内置浏览器里测试“点击后跳转”逻辑，大概率不触发。
- 真要兼容移动端，优先考虑用
dialog元素 + 自定义样式，或轻量库如swal（Sweetalert2） - 若坚持用
confirm()，务必在 iOS 设备上实测：点击后是否卡住、是否丢失焦点、是否影响后续fetch请求 - 部分安卓 WebView（如旧版 QQ 浏览器）会把
confirm渲染成底部弹出，遮挡按钮本身——这时用户点“确定”可能误触下方元素
为什么不要在 confirm 后直接写异步操作
很多人写 if (confirm(...)) { fetch('/api/delete').then(...); }，以为点了“确定”就万事大吉。但 fetch 是异步的，用户点完确认框后，页面没反馈、按钮没置灰、网络请求还可能因用户切页而中断。
这会导致两个真实问题：一是用户重复点击按钮引发多次请求；二是错误未捕获时，界面上看起来“什么都没发生”，但后台已出错。
- 正确做法是：确认后禁用按钮（
e.target.disabled = true），再发起请求，成功/失败后再恢复 - 不要把
confirm()和 API 调用写在同一作用域却不处理 loading 状态——这是线上最常见的交互 bug 来源 -
confirm()本身无 Promise 版本，想链式调用必须封装，例如：function confirmAsync(msg) { return new Promise(r => r(confirm(msg))); }，但注意这仍不能解决 UI 响应问题
