window.confirm 是阻塞式原生确认机制，必须显式判断返回值控制流程，不可用于防刷新/关闭，文案需明确动作后果且语义清晰。
window.confirm 不是装饰性弹窗，它是阻塞式、不可绕过、浏览器原生强制中断执行流的确认机制。用它做二次确认，核心不是“弹出来”，而是“让代码真正停住等用户拍板”——否则风险操作可能早已执行完毕。
confirm() 返回值必须被显式判断并用于流程控制
很多人调用 window.confirm 后没接返回值，或者只打印一下就继续执行，这等于没确认。
常见错误现象：
点击“取消”后，删除请求仍发出去了；表单照样提交；页面照样跳转。
- 必须把
window.confirm的返回值赋给变量，并用if或三元表达式决定是否继续后续逻辑 - 在事件处理器中（如
onclick），直接return window.confirm(...)是最简方式，能天然阻止默认行为 - 不要写成
window.confirm(...); doSomething();—— 这里doSomething()一定会执行，和用户点什么都无关
示例（安全写法）：
button.addEventListener('click', () => {
if (window.confirm('确定永久删除这 3 条记录？此操作不可恢复')) {
fetch('/api/delete', { method: 'POST' });
}
});
confirm() 阻塞主线程，但无法阻止用户刷新或关闭页面
它只暂停当前 JS 执行，不影响浏览器其他动作。这意味着：用户在弹窗出现后按 F5、Ctrl+R、点击关闭标签页，window.confirm 会被直接跳过，你的“确认逻辑”形同虚设。
使用场景：
适用于明确由用户主动触发、且无系统级退出路径的操作，比如按钮点击、表单提交；不适用于防止意外刷新/关闭。
- 要防刷新/关闭，得用
beforeunload事件 + 自定义提示（注意：现代浏览器已限制该事件只能显示通用提示，不能自定义文案） -
window.confirm和beforeunload是两套机制，不能混用或互相替代 - 如果操作本身有服务端幂等性保障（如重复删除无副作用），可降低对前端确认的依赖
confirm() 的文案设计直接影响用户决策质量
它的按钮文字固定为“确定”和“取消”，不支持国际化或自定义。所以文案必须自身就能构成完整的是/否命题，不能靠按钮文字补全语义。
容易踩的坑：
写成“请确认”“是否继续？”——用户点“确定”时根本不知道自己在确认什么；
写成长段技术描述，比如“将调用 DELETE /v1/users/{id} 并清空关联缓存”——普通用户看不懂。
- 用动词开头，明确动作后果：“删除这 3 个文件？”“撤回已发送的邮件？”
- 必要时加关键约束信息：“此操作不可恢复”“24 小时内可撤回”
- 避免模糊词：“可能”“大概”“通常”会削弱确认效力
- 中文句末不用问号也可成立，但务必让“确定”=“同意执行”，“取消”=“中止执行”语义清晰
真正难的不是调用 window.confirm，而是判断这个操作到底值不值得用它——它打断用户，不可跳过，也不可美化。一旦滥用，用户会习惯性狂点“确定”，确认就失效了。该用撤销（undo）、草稿保存、软删除的地方，别硬塞一个 confirm()。
