先把问题拆开：你是普通用户、网页开发者，还是应用开发者？
听起来有点像啰嗦，但真实情况是：创建“窗口”这件事，对三类人有不同的做法和限制。把它分清楚，会让接下来的步骤更有针对性，也少走弯路。
普通用户（只想在手机上多开个窗口或标签）
这部分最直观，也最省心——绝大多数操作都在浏览器界面里完成。
- 点击“+”号新建标签：在比特浏览器右上或底部工具栏通常会有一个加号按钮，轻触即可新建空白标签。
- 长按链接“在新标签/新窗口打开”：当你看到链接时，长按会弹出菜单，选“在新标签中打开”或类似选项，浏览器会在后台打开，不会打断当前页面。
- 使用菜单里的新建窗口/新标签：有些页面可以通过右上三点菜单找到“新建窗口”或“新标签”的快捷项。
- 多窗口和多任务的区别：标签是浏览器内部的页面管理；系统级的“分屏”或多任务属于操作系统功能，不属于浏览器窗口创建范畴。
网页开发者（你希望点击按钮打开新窗口或新标签）
网页想要“创建窗口”，要遵守浏览器的弹窗策略和安全机制。下面是可靠且兼容性较好的做法。
- 尽量用 target=”_blank” 的锚点：例如 <a href=”目标” target=”_blank”>打开</a>。这是最简单、浏览器友好并被允许的方式。
- 用 window.open 但要在用户手势下触发：多数移动浏览器会拦截未经用户交互触发的弹窗。把 window.open 放在点击事件处理函数里，成功率最高。
- 加上 rel=”noopener noreferrer”：这既是安全建议，也能防止新窗口获得对原窗口的 window.opener 访问，避免某些钓鱼或重定向风险。
- 弹窗被拦截怎么办：如果浏览器拦截，通常会在地址栏或工具栏显示被拦截提示，提示用户允许或在设置里放行。作为开发者，不要试图绕过拦截，改为引导用户手动操作或在同页内完成任务。
原生应用开发者（在应用内嵌浏览器 WebView 中创建窗口）
这部分技术细节稍多，但也最关键：应用里默认的 WebView 不像桌面浏览器那样自动管理“新窗口”，需要你在宿主代码里实现。
Android（基于 WebView 的常见做法）
Android 的 WebView 通过 WebChromeClient 提供了 onCreateWindow 回调。当网页执行 window.open 或 target=\”_blank\”，且需要新窗口时，系统会回调这个方法。你的任务是创建一个新的 WebView 或将请求交给宿主去打开新的 Activity/标签。
- 实现要点：在 WebChromeClient.onCreateWindow 中，检查消息（Message）和 WebView.WebViewTransport，创建一个新的 WebView 并将其传回；或者拦截并使用 Intent 在系统浏览器中打开。
- 常见坑：不创建新 WebView 直接返回 false 会导致页面不能打开新窗口；未经用户允许就打开新 Activity 可能影响体验。
- 参考资料：Android Developers 文档里 WebView、WebChromeClient 的说明非常有用。
iOS（基于 WKWebView 的做法）
iOS 的 WKWebView 通过 WKUIDelegate 中的 webView:createWebViewWithConfiguration:forNavigationAction:windowFeatures: 回调处理新窗口请求。
- 实现要点：在该回调中判断 navigationAction.targetFrame，如果为 nil，说明是请求在新窗口打开；你可以创建一个新的 WKWebView 并返回，或将链接交给 Safari 打开。
- 小提示：很多时候，移动端更适合在当前视图控制器打开新链接的页面而不是创建堆叠的 WKWebView，这样更省内存也更符合用户预期。
- 参考资料：Apple Developer 上的 WKWebView、WKUIDelegate 文档。
一张表，快速对比这三种场景
| 场景 | 常用方法 | 注意点 |
| 普通用户 | 点击“+”/长按链接/菜单选择 | 受限于浏览器UI和系统多任务能力 |
| 网页开发者 | target=”_blank”、window.open（需用户交互） | 弹窗拦截、rel=”noopener” 安全设置 |
| 应用开发者 | Android onCreateWindow、iOS WKUIDelegate | 需在宿主中创建/管理新 WebView 或跳转策略 |
常见问题与排查技巧（实用清单）
- 新窗口没打开：检查是否为用户手势触发；浏览器是否拦截弹窗；开发者是否正确返回了 onCreateWindow 或 createWebView 的结果。
- 打开的是空白页：可能是目标 URL 为 about:blank，或者传递给新 WebView 的信息不完整；检查 Message 或 navigationAction 的内容。
- 新窗口拿不到原窗口数据：window.opener 被清空是现代浏览器的安全举措，使用 postMessage 做跨窗口通信，并做好 origin 校验。
- 内存/性能问题：频繁创建 WebView 会占用大量资源，建议复用 WebView 或用系统浏览器打开非关键页面。
安全和用户体验上的提醒
创建新窗口虽然方便，但也要考虑安全与体验：
- 不要滥用弹窗：频繁无提示地打开新窗口会被拦截，且让用户反感。
- 加 rel=”noopener noreferrer”：防止新窗口对原窗口进行恶意操作。
- 告知用户正在打开新窗口：尤其在移动端，用户会担心被重定向或跳出当前任务，适当的提示有助于建立信任。
- 兼容性优先：不同移动平台和浏览器行为不完全一致，优先采用最普遍支持的方案（例如 target=”_blank”），再根据需要做平台定制。
小实验和逐步实现建议（按步骤来更稳妥）
- 先在普通浏览器里用 target=”_blank” 测试链接行为，观察是否被拦截或如何在移动端表现。
- 如果需要脚本控制，再把 window.open 放在点击事件里测试；确认是否需要 rel 属性增强安全。
- 嵌入 WebView 的应用先实现最简单的 onCreateWindow/createWebView 回调，打印收到的参数，确认消息流。
- 根据需求决定是内置新 WebView、复用原 WebView，还是放弃在内嵌内打开而交给系统浏览器处理。
参考资料（名称）
- MDN Web Docs：关于 window.open 与 target 属性的说明
- Android Developers：WebView 与 WebChromeClient 文档
- Apple Developer：WKWebView 与 WKUIDelegate 文档
说这些，可能听起来有点多细节，但其实按类别一步步来就行：作为用户，记住长按和“+”；作为网页作者，用 target 或在用户点击时 window.open 并加上安全属性；作为应用开发者，记得在 WebView 的回调里做好分发和资源管理。嗯，就这些想法，边写边想到的，可能还有别的具体场景会有小差异，如果你有具体的比特浏览器版本号或遇到的错误提示，就更能定位问题。