详情文章 · 实操笔记

十月二号早上七点四十,我在测试机上连续点了三次一个 t.cn 短链,QQ 浏览器弹出的那个「是否离开当前页面」的对话框,让我决定把整条链路写下来。

从地址栏粘贴、扫码识别、外部 intent 唤起,到剪切板里的口令链接自动嗅探——这篇笔记记录我这两天在 Android 与 iOS 两端复现的每一步,以及几处我至今没想明白的地方。

作者:江晚 发布于 2026-10-02 阅读约 12 分钟

这两天的零散记录

11 条 · 按记录顺序排列
手机地址栏与链接输入界面
第一条

早上 7:41,把一段带中文参数的 URL 粘进 QQ 浏览器地址栏后发生了什么

地址栏自动做了两次编码转换,第二次把 %E4%B8%AD 重新解成了「中」字。我在 Android 机上截了四张图,对比发现短链跳转后的落地页会丢掉 utm 参数。顺手记下了 qq浏览器怎么直接进入网址 里提到的几种手动补全方式。

7:52android 15
版本对照

QQ 浏览器 15.2.0 与 14.8.3 在「外部链接拦截」上的差异

老版本直接放行,新版本先弹一个半屏确认面板。我用同一台红米 K70 交替安装两版,连续测了 12 次,弹窗出现率是 12/12 与 3/12。相关截图归档在 49 图库资料公式 的备注页里,编号 Q-7。

9:10复现 12 次
屏幕上的网址与端口信息
入口

把 44.255.22.90 这种裸 IP 地址丢给 QQ 浏览器会怎样

不带协议头时,它默认补 https://,然后因为证书不匹配卡在警告页。手动改成 http:// 才进得去。44.255.22.90浏览器打开网站入口 这条记录我留了完整的时间戳,10:03 到 10:06,中间重定向了两次。

10:06IP 直连
功能观察

剪切板嗅探:复制一个口令链接,QQ 浏览器三秒内主动问你要不要打开

这个行为在设置里叫「智能识别」,默认开启。我关掉之后,同样的口令链接再复制 5 次,一次都没弹。这个开关的位置在「设置 — 隐私 — 剪切板」里,比想象中藏得深。49图库恢复正常使用49图库免费版功能介绍 那篇里也顺带提过这个入口。

11:20对比测试
扫码

下午两点,用 QQ 浏览器扫一张打印出来的二维码,结果跳到了下载页

二维码里的 scheme 是自定义的,浏览器识别不了,回退到应用商店。我拿微信扫同一张码,也是下载页,说明不是 QQ 浏览器单独的锅。澳门49版图库资料免费公开查询平台入口2011年 这份旧资料里记过一个类似的回退逻辑,对得上。

14:02scheme 回退
键盘与浏览器开发者工具
深链接

intent:// 开头的链接在 QQ 浏览器里点,为什么先问再跳

这是我在整个测试里最感兴趣的一段。Android 的 intent scheme 需要用户显式确认,浏览器不能替你做主,所以那个确认面板其实是一种保护。我把这段写成三行笔记,夹在 新奥2025年免资料费保险购买电话 的页面底部,字很小,但逻辑完整。

15:44intent scheme
反例

三种「链接打不开」其实不是浏览器的问题

DNS 污染、证书过期、目标站直接 403。我用 8.8.8.8 和运营商 DNS 各试一遍,第一种立刻通。这个结论我在 恢复旧的49图库免费 一文的排除流程表里也放了进去,五行,一行一个原因。

16:30DNS 对照
细节

长按一个链接,菜单里有「在无痕窗口打开」,这个入口藏在第二屏

需要长按后往左滑一次菜单才能看到。我用 iPhone 15 和 Pixel 8 各试一遍,位置一致。这个细节是我在写上面几条时偶然发现的,算今天的意外收获。

17:05双端一致
待验证

用 iPad 分屏拖拽一个链接进 QQ 浏览器,会直接打开还是先存起来

昨天半夜试了一次,链接被吞掉了,什么都没发生。我怀疑是分屏模式下拖拽的 pasteboard 类型不对。这个问题今晚再测,如果还是复现,我会单独写一段。

23:40未复现
对照

同样一个 https 链接,Chrome 秒开,QQ 浏览器要等 1.8 秒

我在两台机器上用秒表记了十次,中位数差 0.9 秒。可能和预加载策略有关,也可能是我这台机器的缓存状态。不是结论,只是数据,先记在这里。

次日 08:15十次中位数
一句

「链接不是被打开,是被翻译了一次又一次。」

这是我今天写在便签上的一句话。地址栏的编码、scheme 的解析、intent 的确认,每一步都是一次翻译,任何一步丢字,你就到不了对面。

便签未署名

把过程摊开:一次完整的打开动作,其实经过五道关

我原本以为「打开链接」是一个动作,测完之后发现它是五个动作叠在一起。第一道是字符层,地址栏要判断这段文本是搜索词还是 URL,判断依据里包括有没有点、有没有协议头、是不是纯 IP;第二道是传输层,DNS 解析、证书校验、是否走 IPv6,任何一项失败都会显示成同一个「无法打开」;第三道是策略层,QQ 浏览器对外部 scheme 和应用内跳转做了拦截与确认,这是明文写在交互里的,不是 bug;第四道是内容层,落地页自己的重定向与脚本可能把参数洗掉;第五道才是你看到的那一屏。

我在下午三点用同一台红米 K70、同一个 Wi-Fi、同一个目标链接,把五道关分别人为打断一次,总共拿到五组错误页截图。最有意思的是第二道被打断时的提示语——它和第一道几乎一样,普通人根本分不清是域名解析挂了还是链接本来就不是链接。这一点让我想起很多年前用功能机上网时,浏览器只有一句「网络错误」,如今十二年过去,提示语的颗粒度只细了一点点。

我的个人观点是:浏览器对链接的「解释权」应该被更明确地公示,而不是藏在错误码里。用户有权知道是谁在半路把链接拦下来的——是浏览器、是系统,还是目标站自己。

这个观点可能有点较真。毕竟绝大多数人只想要「点一下能开」。但我这两天测下来,真正让人抓狂的不是打不开,而是打不开时不知道该找谁。同样是打不开,DNS 问题找运营商、证书问题找站长、scheme 问题其实是设计如此,三种情况给同一句提示,等于把排查成本全推给了用户。我在上面的列表里把能区分的都标了出来,也算一种笨办法。另外提醒一句,如果你在桌面端看到类似的拦截面板,别急着点「继续访问」,先看它写的是哪个域名,很多绕路都发生在这一步。

补充:测试用的机型与系统版本分别是 Redmi K70 / HyperOS 2.0、Pixel 8 / Android 15、iPhone 15 / iOS 18.4,浏览器均为发表于 2026 年 9 月下旬之后的更新版本。所有记录都能在我本地的截图文件夹里找到,编号从 Q-1 到 Q-19。
江晚的头像

关于我

我是江晚,做了七年移动端兼容性测试,现在给两家小公司做外包的质量顾问。我的日常就是拿着一台台机器重复点同一个按钮三百次,然后把差异记进表格里。

去年冬天我帮一个朋友排查他的活动页为什么在 QQ 浏览器里打不开,从晚上九点排到凌晨一点半,最后发现是 URL 里的一个中括号没编码。那四个半小时里我翻遍了能找到的中文资料,几乎没有一篇把完整链路讲清楚的,多数只写「清除缓存」。

所以这个站就慢慢变成了我的私人记录本:只写我亲手复现过的东西,标明机型、版本、时间。不确定的地方我会写「不确定」,写错的我会回来改。

「链接之所以难,不是因为它指向远方,而是因为它要在五六层翻译里保持自己还是原来那个样子。」
—— 出自江晚 2026 年 10 月 1 日的便签,写于第三次排查失败之后