window.open()才是打开新页面的正确方式，alert/confirm等弹窗无dom且不可交互；它返回window对象支持完整api，但需用户手势触发、注意跨域通信与移动端兼容性。
弹窗不是页面，window.open() 才是打开新页面的正确方式
HTML 里没有“把弹窗设置为一个页面”的概念。所谓弹窗（比如 alert()、confirm()）是浏览器原生阻塞式对话框，不能加载 HTML、不能写 CSS、不能执行 JS —— 它们连 DOM 都没有，更谈不上“是一个页面”。真要打开一个独立、可交互、带完整文档结构的页面，必须用 window.open()。
常见错误是试图用 dialog 元素或 modal 框架冒充“新页面”，结果发现 URL 不变、前进后退无效、无法书签收藏、也不支持多窗口协作 —— 这些都是因为它压根没脱离当前页面上下文。
-
window.open()返回的是一个Window对象，它拥有完整的document、location、history，和主窗口地位平等 - 不传 URL 参数会打开空白页（
"about:blank"），可后续用win.document.write()注入内容，但更推荐直接指定 HTML 路径 - 第二个参数是窗口名（如
"myPage"），相同名字多次调用会复用已有窗口，而非反复弹新窗 - 第三个参数控制尺寸/位置/工具栏等，例如
"width=800,height=600,menubar=no,toolbar=no"；但现代浏览器普遍限制对地址栏、关闭按钮等关键 UI 的隐藏
window.open() 被拦截的典型表现和绕过条件
用户点击触发前调用 window.open()（比如在 setTimeout 里、或异步请求回调中）几乎必被浏览器拦截，控制台会报 Blocked opening 'xxx' in a new window because the request was made without user activation.。
能成功打开的唯一可靠前提：调用必须直接发生在用户手势事件处理器内，且不能被 Promise 或定时器延迟。
立即学习“前端免费学习笔记（深入）”；
- ✅ 正确：
button.addEventListener("click", () => window.open("/page.html", "_blank")) - ❌ 错误：
fetch("/data").then(() => window.open("/page.html"))（异步回调，无用户激活上下文） - ❌ 错误：
setTimeout(() => window.open("/page.html"), 100)（脱离事件栈） - ⚠️ 注意：
target="_blank"的链接是 HTML 行为，不受 JS 拦截规则约束，但它开的是标签页而非可编程控制的窗口
新页面和父页面通信：别依赖 window.opener 直接读写
子页面可通过 window.opener 访问父窗口，父页面也能通过 window.open() 返回的对象访问子页面，但这只在同源时安全可用。跨域时 window.opener 是 null，且所有属性访问都会抛 DOMException。
真正健壮的通信必须走 postMessage()，双方监听 message 事件，并校验 event.origin。
- 父页发消息：
newWin.postMessage({ type: "INIT", data: 123 }, "https://example.com") - 子页监听：
window.addEventListener("message", e => { if (e.origin === "https://parent.com") { /* 处理 */ } }) - 不校验
origin可能导致 XSS，尤其当子页面加载的是第三方 URL 时 -
window.close()只能在自己打开的窗口上调用，否则静默失败 —— 子页不能关掉父页，父页可以关掉子页（newWin.close()）
移动端和 PWA 场景下 window.open() 的实际表现
在 iOS Safari 和多数 Android 浏览器里，window.open() 默认行为是打开新标签页（tab），而非传统意义上的弹窗；你传的 width/height 参数完全被忽略，也无法禁用地址栏。
PWA（添加到主屏幕后）环境更严格：部分安卓 WebView 会直接拒绝 window.open()，返回 null；iOS PWA 则根本不会响应该调用 —— 看似静默，实则失效。
- 不要假设窗口尺寸可控，尤其不要用它做“伪桌面应用”布局
- 需要确定性新页面体验？优先用
<a href="/page.html" target="_blank"></a>，它兼容性更好，且至少能保证跳转发生 - 若必须 JS 控制，务必检查返回值：
const w = window.open(...); if (!w || w.closed) { /* fallback to location.href or toast */ }
真正的难点从来不是怎么写那行 window.open()，而是想清楚：这个“页面”是否真的需要脱离当前上下文？它的生命周期谁来管理？用户关掉它之后，主流程怎么继续？这些问题没答案，代码写得再准也没用。
