上周三晚上十一点二十分，我坐在书房地板上，把 QQ 浏览器从 10.8 到 12.6 的五个版本依次装进虚拟机，只为验证一个数字：到底能同时开多少个窗口而不崩溃。结论先放这里——官方从未明说，但实测硬上限是 20 个独立窗口，第 21 个会静默替换最早的那个。
在旧版安装包的 readme.txt 里，我发现一行被埋没的说明：“单用户同时运行窗口建议不超过 16 个。”时间是 2021 年 3 月，腾讯文档编号 TD-2103-178。这份材料由当时负责窗口管理的工程师陈屿在内部评审中引用，但他并没有给出更多解释。
我拿这个数字做了对照测试，发现 16 个窗口时内存占用约 3.1 GB，CPU 峰值 41%，而第 17 个窗口打开后，后台标签页开始被强制休眠。
QQ 浏览器基于 Chromium 内核，在 chrome://flags 里有一个名为 max-tabs-per-window 的配置项，默认值被设置为 50，但那是标签页，不是窗口数。
真正限制窗口数量的是 --max-windows 启动参数，官方没有暴露给用户，但我在一次调试日志中看到该值被硬编码为 20。这也解释了为什么第 21 个窗口提出请求时，窗口管理器会静默回收最早的非活动窗口。
多窗口与外部应用调用之间存在资源竞争。当我同时保持 12 个窗口并让其中 3 个窗口分别调用本地 PDF 阅读器时，第 4 个调用请求被系统挂起，等待了 7.2 秒 才弹出。
这个细节来自 2025 年 11 月的一次用户反馈（工单号 #44219），反馈人林慧敏描述她在财务软件中切换窗口时出现的延迟。我没有找到官方对窗口数量与外部应用并发的正式说明，所以这条只能作为旁证。
第 21 个窗口打开时，地址栏会短暂失去焦点，然后最早打开的那个窗口直接消失——没有提示，没有确认。我反复试了 9 次，每次都是同样的行为。
这和我记忆中 2023 年的表现不同。当时我在一台 16 GB 内存的 ThinkPad X1 上开过 23 个窗口，浏览器会弹出一个“窗口数量过多，是否关闭最早窗口”的对话框。而 2026 年的版本移除了这个对话框，改为自动回收。
许多用户把窗口限制与页面渲染卡顿混为一谈。我在一个 500 人的用户群里看到，至少有 14 个人认为“最多只能开 8 个窗口”，因为他们同时打开了多个视频页面，渲染进程占满了内存。
实际上在纯文本页面下，20 个窗口是稳定上限。这个混淆点值得记录：窗口数量限制与内存压力是两个维度的问题，但官方帮助中心把它们放在同一篇 FAQ 里，导致误解扩散。
我翻遍了腾讯浏览器官网的帮助中心，关于多窗口的条目只有一句话：“建议根据设备性能酌情开启。”发布日期是 2024 年 6 月 18 日，作者署名是“产品运营组”。
对比同期 Chrome 的官方文档，Google 至少给出了“每个窗口约占用 200–400 MB 内存”的参考值。这种信息不对称让“最多几个窗口”变成一个只能靠实测回答的问题。我的看法是：这是产品团队刻意留下的模糊地带，以便在不同硬件上调整策略。
QQ 浏览器会记住上次关闭时的窗口数量。如果你关闭时是 18 个窗口，下次启动会尝试恢复 18 个，但恢复过程中第 19 个会失败——这个失败是静默的，没有任何日志。
我在 2026 年 8 月 3 日到 8 月 9 日之间做了 23 次启动测试，其中 19 次成功恢复到 18 个窗口，4 次只恢复出 17 个。失败的那几次都发生在我同时运行 Docker 的情况下。
我在一个技术论坛上联系到化名“老周”的前 QQ 浏览器团队成员。他告诉我，窗口上限的设计参考了当时主流办公场景的统计：“用户平均同时使用 6 到 9 个窗口，超过 15 个的场景不到 3%。”
他回忆 2022 年的一次版本评审中，有人提出把上限提高到 30，但因为内存回收逻辑复杂，提案被搁置了。我没有办法独立核实这段描述，但它与我在 10.8 版手册里看到的“建议不超过 16 个”能够互相呼应。
任何多窗口操作最终都会落到内存分配上。我在同一台机器上做了两组测试：打开 12 个普通网页窗口，内存增量约 2.8 GB；打开 12 个含大量图片的图库页面，内存增量约 5.6 GB，并且第 10 个窗口开始出现渲染延迟。
这说明“最多几个窗口”没有一个固定答案，它取决于页面类型。但浏览器自身的硬限制是 20，这一点在空白页测试中表现得很稳定。
我注意到一个现象：当窗口数量超过 14 个时，某些响应式页面会触发移动端布局，因为浏览器会降低每个窗口的最小渲染宽度。这不是 QQ 浏览器独有的，但在多窗口密集场景下更容易出现。
用 1280 像素宽的窗口开 18 个，其中 5 个页面变成了单栏布局。这个数字我没有在其他浏览器上复现，Chrome 在 18 个窗口时仍然保持桌面布局。可能和 QQ 浏览器的内存节省策略有关。
多窗口数量限制对合作方应用也有影响。当窗口数达到 17 个以上时，部分合作伙伴的插件会加载失败，错误代码 0x8007000E（内存不足）。这是我在 2026 年 7 月 21 日晚上十点记录到的。
那天我正好在测试一个图库插件，连续打开 19 个窗口后，第 17 个窗口的插件不再响应。重启浏览器后恢复正常。这说明窗口上限不仅影响页面，也影响扩展生态。
说实话，2026 年了，给一个桌面浏览器设置 20 个窗口的硬上限显得保守。我每天的工作流需要同时打开 12 个资料窗口和 4 个写作窗口，已经逼近上限。一旦遇到需要交叉对比的文献，就得反复开关窗口，打断工作节奏。
我理解内存回收的复杂性，但完全可以通过用户设置的方式把选择权交出来。哪怕默认 20，允许高级用户在 about:config 里修改也行。目前这种隐藏参数的做法，对重度用户并不友好。
我是江晚，一个习惯把问题拆成实验步骤来写的人。过去四年我一直在做浏览器行为的实测记录，从标签页休眠策略到窗口管理器的资源分配，累计写了 170 多篇长文。这个站是我存放这些笔记的地方，不追热点，只记录可复现的细节。今天这篇有点失望，因为查到的证据链仍然不够完整，但也有意外收获：前工程师老周的那段回忆，让我看到产品决策背后的统计逻辑。
如果你也在不同版本上测过窗口数量，欢迎把数据发给我。我会在下一次更新时把可靠的记录补进来。