4 月 7 日晚上 11 点 40 分，我在 QQ 浏览器里第 7 次点掉同一个弹窗，然后决定把设置逐项抄下来。

qq浏览器关闭弹出窗口：一次还没有结论的实测

4 月 7 日晚上 11 点 40 分，我坐在书桌前，第三次刷新同一个小说目录页。页面右下角第 7 次弹出一个大约 320 像素宽的浮层，右上角有一个浅灰色的关闭叉。我点掉它，等了四秒，它又出现了。那一刻我意识到，问题不在于「怎么关」，而在于我根本不知道这个弹窗是从哪里来的——是 QQ 浏览器的拦截没生效，还是这个站点用了一种拦截规则覆盖不到的方式把它推出来的。这两种情况的解决办法完全不同，而大部分教程把她们混为一谈。

我先做的事情很笨：把设置界面完整抄了一遍。在 QQ 浏览器 12.x 的桌面版里，「设置 → 隐私和安全」下面确实有三个和弹出窗口沾边的条目。第一个是全局的「拦截弹出窗口」，默认开启；第二个是「允许特定网站弹出窗口」的白名单；第三个藏在「内容设置」里，叫「阻止网站发送通知请求」。我用 A、B、C 给她们编号，然后逐个做单变量测试。关掉 A 之后，浮层照旧；关掉 B 之后，出现频率大概减少了一半；只有三个同时关掉，那个页面才真正安静下来。这个结果让我困惑，因为从命名上看，C 和页面内浮层几乎没有关系。

为了验证这个判断，我写了一个只有 40 行的测试页面，里面放 5 个触发点：两个直接用 window.open，两个放在 onclick 里套一层 setTimeout，最后一个用 div 加 fixed 定位模拟页面内浮层。结果在 Chromium 内核的 Edge 上，5 次 window.open 全部被拦；在 QQ 浏览器上，3 个被拦，两个带 setTimeout 的漏了过去，而那个 div 浮层，两个浏览器都没有做任何处理。这说明拦截逻辑主要识别同步的用户手势，异步延迟调用会绕过一部分规则。我把这个发现记在笔记本第 41 页，旁边画了一个问号，因为样本只有 5 个，我不敢说这是普遍规律。

第二个让我卡住的地方是白名单。我的「允许弹出窗口的网站」列表里躺着一条 2019 年加入的域名，是一个早就改版的阅读站。按常理，白名单应该让弹窗更容易出现，可我清空它之后，那个站的目录页反而正常了。我反复试了三次，每次都一样。我的猜测是：白名单里的旧条目让拦截逻辑走了一条兼容分支，而那条分支对现代前端的判断更宽松。这只是猜测，我找不到文档佐证，问过两个做前端的同事，他们也说不清。所以我把她写下来，而不是当成结论——写作这件事，诚实比完整更重要。

还有一个角度值得提。拦截成功不等于体验正常。有一次弹窗被干净地拦下了，页面主体却白屏。打开开发者工具才发现，站点把页面渲染的下一步写在弹窗的 close 回调里，窗口根本没创建，回调自然不执行，于是整页停在那里。这已经不是浏览器设置能解决的问题了，它属于站点自身的健壮性缺陷。类似的情况我在整理 404网站入口浏览器打开 那篇笔记时也遇到过，表现形式不同，底层原因惊人地相似：把关键逻辑挂在一个可能不存在的对象上。

折腾到凌晨一点，我关掉电脑，问题列表比开始时更长。我知道全局开关在哪里，知道白名单会影响判断，知道异步调用会漏，也知道 div 浮层拦不住——但我仍然不知道，一个普通用户面对第 7 次弹出的浮层时，最短的解决路径到底是什么。也许答案不是设置，而是换一个访问方式，或者干脆放弃那个站点。这个答案不够漂亮，可它是目前唯一一个我能用实测支撑的。明天我打算再测一遍移动端，安卓版把选项藏在「网页浏览设置」的第三层折叠菜单里，路径和桌面端完全不同，这件事本身就该被记录下来。