window.confirm()是唯一简单可靠的退出登录确认方案，它原生阻塞跳转、返回布尔值，需配合e.preventDefault()使用，不可用alert或自定义模态框替代，且无法修改样式。
用 window.confirm() 实现退出登录确认最简单可靠
浏览器原生的 window.confirm() 是唯一无需引入库、兼容所有现代浏览器、且能阻塞页面跳转流程的方案。它返回布尔值，true 表示用户点了“确定”，false 表示点了“取消”或关闭弹窗。
直接在点击退出按钮的事件中调用即可，比如：
document.getElementById('logout-btn').addEventListener('click', function(e) {
e.preventDefault();
if (window.confirm('确定要退出登录吗？')) {
window.location.href = '/logout';
}
});
注意必须加 e.preventDefault()，否则链接会先跳转，确认框来不及弹出。
不要用 alert() 或自定义模态框替代确认逻辑
alert() 只有“确定”按钮，无法实现“确认/取消”二元选择，不能阻止后续操作；而用 div 模态框（如 Bootstrap Modal）虽美观，但它是异步的——用户点“确定”后才触发退出，中间可能刷新、跳转或重复提交。
立即学习“前端免费学习笔记（深入）”；
常见错误包括：
- 把
confirm()放在异步请求回调里（比如登出接口返回后再弹），此时页面可能已跳走或状态失效 - 用
async/await包裹confirm()（它不是 Promise，不支持 await） - 监听
beforeunload时误用confirm()（该事件只允许返回字符串，且现代浏览器已限制其行为）
confirm() 的文案和样式无法自定义，这是刻意设计
浏览器禁止修改 confirm() 的外观和按钮文字，这是出于安全考虑——防止钓鱼页面伪造系统提示。所以别浪费时间查“怎么改 confirm 样式”，没有合法途径。
如果产品硬性要求定制 UI，只能放弃阻塞式确认，改用「点击后禁用按钮 + 显示临时提示 + 用户二次点击确认按钮」的流程，但必须额外处理以下问题：
- 防止用户连续点击导致重复请求（需设
disabled或节流） - 网络失败时要恢复按钮可点击并提示错误
- 退出成功后跳转前需清空本地 token、清除 session storage 等状态
移动端 Safari 对 confirm() 有特殊表现
iOS Safari 在某些上下文中（如从 PWA 添加到主屏幕后）可能不显示 confirm()，或点击无响应。这不是 bug，而是 Safari 对非用户手势触发的弹窗做了更严格限制。
确保触发 confirm() 的代码一定发生在用户真实点击（click）或触摸（touchend）事件回调内，避免包在 setTimeout、Promise.then 或其他异步回调中。
如果仍不可靠，降级策略是：先跳转到一个中间页（如 /logout/confirm），页面上放标准 HTML 按钮供用户二次确认——虽然体验稍差，但 100% 可控。
真正麻烦的从来不是写几行 JS，而是用户在点击“确定”那一瞬间，页面状态是否还一致、token 是否已被清空、后端会话是否已失效。这些边界情况比弹窗本身更值得花时间检查。
