window.close()仅能关闭由window.open()脚本打开的同源窗口，且需在用户同步操作中调用；手动打开的标签页、跨域窗口、iframe内调用及移动端均被现代浏览器静默禁止。
用 window.close() 关闭当前窗口的限制条件
直接调用 window.close() 在大多数现代浏览器中不会生效，除非该窗口是通过 window.open() 脚本打开的。这是浏览器安全策略强制执行的限制——用户手动打开的标签页（比如输入 URL 或点击书签）无法被脚本关闭。
常见错误现象：window.close() 静默失败，控制台无报错，但页面依然存在；部分浏览器（如 Chrome 97+）甚至会抛出 DOMException: Blocked a frame with origin ... from accessing a cross-origin frame 类似提示（如果在 iframe 中误调用）。
- 仅对
window.open()创建的窗口有效，且需保存其引用（例如const win = window.open(...)） - 若目标窗口已失去焦点或被用户切换走，
win.close()仍可执行，但部分浏览器会弹出二次确认（如 Firefox） - 移动端 Safari 和 Android Chrome 基本不支持任何脚本关闭行为，无论来源
替代方案：用 location.replace() 模拟“关闭”效果
当真实关闭不可行时，更可靠的做法是把当前页面替换成空白页或跳转到一个无内容页，视觉上等效于关闭。这绕过了权限限制，且兼容所有环境。
使用场景：表单提交成功后自动退出、扫码登录回调页、临时弹窗页（非 window.open 打开）需要清理自身。
-
location.replace('about:blank')最轻量，不留下历史记录，用户无法点返回回到原页 -
location.replace('/closed.html')可自定义提示文案（如“操作已完成，页面将自动关闭”），再配合setTimeout(() => window.close(), 1000)尝试补一刀（仅对 script-open 窗口有效） - 避免用
location.href = '...'，它会保留当前页在 history 中，用户点返回会重新加载原逻辑
监听页面卸载时机：用 beforeunload 提示而非强制关闭
如果目标是防止用户误操作离开，而不是主动关闭，beforeunload 是唯一受支持的干预入口。它不能阻止关闭动作本身，但能触发浏览器原生确认对话框。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
注意：Chrome 88+ 已移除自定义提示文案能力，只显示统一提示（如“您确定要离开此页面吗？”），且仅在用户有未保存更改等“脏状态”时才触发（部分浏览器要求事件监听器内必须有同步副作用，如赋值）。
- 注册方式：
window.addEventListener('beforeunload', e => { e.preventDefault(); return ''; }) - 返回值
''或undefined才触发提示；返回字符串在旧版浏览器中曾用于自定义文案，现已无效 - 该事件不适用于自动化关闭流程，仅用于用户交互防护
iframe 内关闭父窗口？基本不可行且危险
嵌入在 iframe 中的页面尝试执行 window.parent.close() 或 window.top.close() 几乎必然失败，并大概率触发跨域错误（Blocked a frame from accessing a cross-origin frame），即使同域也可能因浏览器策略拦截。
真正可行的路径只有两种：
- 父页面主动暴露一个受控函数（如
window.allowClose = () => window.close()），且 iframe 与父页同源；子页调用前需校验该函数是否存在并具备调用权限 - 通过
postMessage向父页发送关闭请求，由父页自行判断是否执行window.close()（仍受限于前述 script-open 规则） - 绝大多数 SaaS 嵌入场景（如微信公众号网页、钉钉微应用）明确禁止关闭宿主窗口，强行尝试可能被平台封禁
真正的难点不在语法，而在浏览器策略的碎片化和持续收紧。别执着于“关掉它”，先确认这个动作是否真的必要——很多时候，重定向 + 清理状态比模拟关闭更稳定、更少埋坑。
