window.close()无法触发确认弹窗，仅对window.open()打开的窗口有效；beforeunload是唯一可干预时机，但仅显示统一提示，且需标记“脏状态”才生效，confirm等交互被静默屏蔽。

浏览器原生 window.close() 不能触发确认弹窗

现代浏览器（Chrome、Firefox、Edge）出于安全限制，window.close() 只对 window.open() 打开的窗口有效，且默认不弹确认框；直接调用它不会触发“关闭后不可恢复”提示，用户甚至可能毫无感知就关掉了页面。

这不是 bug，是规范行为——防止恶意网站滥用关闭弹窗干扰用户。

• 手动点击浏览器右上角 × 或按 Alt+F4 / Cmd+W：浏览器**完全不给你拦截机会**，JS 无权介入
• beforeunload 是唯一可干预的时机，但它只支持返回字符串（且现代浏览器已屏蔽自定义文案），实际只显示统一提示：“离开此页面？您输入的数据可能不会被保存。”
• 想显示“关闭后不可恢复”，必须靠前端自己做视觉引导，而非依赖系统弹窗

beforeunload 事件怎么写才真正生效

这个事件不是“你想拦就能拦”，它有硬性触发条件：页面必须有未提交的表单、或 JS 主动标记过“脏状态”。空页面或纯静态页注册了也白搭。

关键不是加事件，而是让浏览器认可“确实有东西要丢”：

立即学习“前端免费学习笔记（深入）”；

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• 在用户输入、修改、上传等操作后，设一个标志位：let isDirty = true
• 在 beforeunload 回调里返回非空字符串（哪怕只是 "1"），但注意：Chrome 98+ 会忽略内容，只显示标准提示
• 别在回调里写异步逻辑（比如 fetch 或 confirm()），它会被立即忽略
• 示例：

  window.addEventListener('beforeunload', (e) => {
    if (isDirty) {
      e.preventDefault();
      e.returnValue = '关闭后未保存的内容将丢失';
    }
  });

为什么 confirm() 放 beforeunload 里没用

因为 beforeunload 的执行期不允许阻塞式交互——confirm()、alert()、prompt() 全部被浏览器静默屏蔽，控制台可能报 Blocked attempt to show a 'confirm' dialog。

你看到的“空白弹窗”或“无反应”，其实是浏览器主动截断了 JS 的 UI 请求。

• 想让用户看到自定义文案，只能提前在页面显眼处放一个浮动提示（比如顶部 banner），文字写清楚“您有未保存的设置，关闭将丢失”
• 配合按钮控制关闭流程：比如“暂存并关闭”“放弃并关闭”，而不是等用户点 × 才提醒
• 真要模拟确认流，得放弃监听关闭，改用主动按钮触发：document.getElementById('close-btn').onclick = () => { if (confirm('关闭后不可恢复，确定吗？')) window.close(); }

移动端和 PWA 场景下更麻烦

iOS Safari 和大多数 Android 浏览器压根不支持 beforeunload 的提示效果；PWA 被添加到主屏幕后，window.close() 直接无效，beforeunload 也可能被跳过。

这意味着：依赖弹窗确认的逻辑，在手机端大概率失效。

• 不要假设用户会看到提示——把“防误关”逻辑前置到交互层，比如表单离开前自动草稿保存
• 用 localStorage 持久化关键状态，下次打开时检查并询问是否恢复
• 如果业务强依赖“不可逆关闭”，考虑改用模态对话框模拟“退出”动作，而不是真依赖浏览器关闭行为

事情说清了就结束。最常被忽略的点是：你以为在监听关闭，其实浏览器只给了你一个“打个招呼”的机会，连话都说不全。