最简写法是onclick="return confirm('确定要删除吗？')"，需用return显式返回confirm结果以阻止默认行为；confirm不可定制样式且无回调，仅适用于低要求内部工具。
点击按钮触发 confirm 弹窗的最简写法
直接在 onclick 里调用 confirm() 就能弹出原生确认框，但要注意它会阻塞后续 JS 执行，且返回值必须显式处理，否则点击“取消”也会提交表单或跳转。
-
confirm("确定要删除吗？")返回true（确定）或false（取消），不能忽略这个返回值 - 如果按钮是
<button type="submit"></button>或在表单内，confirm()返回false时必须return false阻止默认行为 - 避免写成
onclick="confirm('...');"—— 这样不管点“确定”还是“取消”，都会继续执行
防止表单误提交的典型写法
常见错误是没拦截取消操作，导致用户点了“取消”仍触发提交。关键在于把 confirm() 的返回值直接作为事件处理器的返回值。
-
return confirm(...)中的return是给onclick用的，不是给函数体返回的 - 如果用独立函数，必须显式
return：onclick="return handleDelete()"，且handleDelete函数末尾写return confirm(...) - 注意：现代框架（如 React）中不推荐直接操作 DOM 事件，应改用
event.preventDefault()+ 状态控制
confirm 在不同浏览器里的表现差异
confirm() 是浏览器原生 API，所有主流浏览器都支持，但样式和交互细节不可定制，且在 iOS Safari 中可能被拦截（尤其快速连续触发时）。
- 无法修改按钮文字（固定为“确定/取消”），也不能加图标或改变颜色
- 在 Electron 或某些 WebView 环境中，
confirm()可能被禁用，需 fallback 到自定义模态框 - 移动端双击缩放、页面滚动等交互下，弹窗偶尔会错位或响应延迟，属于已知限制，无绕过方案
什么时候不该用 confirm()
当需要支持国际化、自定义文案、键盘操作（如按 Enter 确认）、或与页面样式统一时，confirm() 就不合适了——它本质是调试级 API，不是 UI 组件。
- 多语言项目必须用自定义弹窗，因为
confirm()文案不可替换 - 涉及敏感操作（如支付、权限变更）时，业务方通常要求记录用户选择日志，而
confirm()不提供回调钩子 - 若页面已引入
Ant Design、Element Plus等 UI 库，直接用其Modal.confirm更可靠，例如：Modal.confirm({ title: '提示', content: '确定要提交吗？' })
真正要用 confirm() 的场景其实很窄：内部工具页、临时调试、或对 UX 要求极低的后台管理按钮。一旦需求稍复杂，就得切到可控方案。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
