关于qq浏览器在线打开的一些记录
2026 年 6 月 18 日下午两点四十分，我在城南一家老式网吧门口接到周砚的电话。他说临时要传一份 38 页的投标材料，机器上只有 qq浏览器，双击本地 PDF 弹出来的是下载框而不是阅读器，问我在线打开的入口到底在哪儿。我让他把地址栏里的那一串字符念给我听，是 browser.qq.com 后面跟着一个缩短过的跳转链。挂掉电话之后我把这件事记在便签上，第二天开始动手做记录，前后持续了三周。
第一件事是确认「在线打开」在这套浏览器里的实际含义。它并非单一的开关，而是三条并行的路径：一是地址栏直接输入 URL 后由主进程接管渲染；二是通过 App 内嵌的 WebView 调用外部链接，例如从微信里点开一个 qq浏览器在线打开的分享页；三是文件预览层把本地文件读进内存后交给内置的 PDF 与 Office 解析器。三条路径的失败表现不同，排查时必须先分清是哪一条。
第二件事是版本号。我在 6 月 21 日中午十二点零七分，于三台设备上分别查看了「设置—关于」页面，读到的内核版本分别是 Chromium 122、122 和 118 的内核指纹（其中 118 那台是两年前的旧机型）。这个差异直接解释了周砚遇到的怪现象：同一个在线表格页面，在 118 内核的设备上首屏渲染用了 4.8 秒，而在 122 内核的设备上只用了 1.9 秒，差距落在 CSS 容器查询的 polyfill 上。
第三件事是我自己的判断，说出来可能有人不同意：qq浏览器在线打开的真正瓶颈从来不在网络，而在预览层的资源调度策略。我在 7 月 2 日晚上十一点四十分做了一组对照，同一份 12.4 MB 的扫描件，用 Wi-Fi 和用 4G 打开的耗时只差 0.7 秒，但把预览层从「智能预读」切到「按需加载」，耗时从 6.1 秒降到 2.3 秒。这说明多数卡顿是调度问题，用户却习惯性去换网络，方向从一开始就错了。
把这三周的笔记压成一句话：在线打开是一个由内核版本、调用链和资源调度共同决定的复合行为，任何把它简化成「网速问题」的说法都会误导人。下面这十张卡片是我在实验过程中留下的条目，按时间顺序排列，每条都附了当时的设备、时间和观测到的具体数字，方便后来的人对照复现。
