12 月 9 日下午三点，我坐在书桌前，准备把同事发来的一个 .pages 文件转成 PDF。我用的是手机，系统是 Android 14，qq浏览器版本 14.8.0，文件躺在“最近文件”里，大小 2.3 MB，创建时间是 2019 年 6 月。我点了一下，屏幕闪了一下，然后停在“正在加载”的灰色界面上，整整 17 秒，什么反应也没有。
我退出重进，换了 Wi-Fi 和 5G，重启了 app，清理了缓存。同样的灰色界面，同样的沉默。于是我开始认真记录这件事——倒不是为了这篇文字，而是因为同一天里，我一共遇到了三个打不开的文件，每一个都指向不同的原因。
第一个文件是 .pages，第二个是一张 12MB 的 .dwg 施工图，第三个是一份 47 页的 .epub 电子书。三个文件，三个不同的失败方式。
先说第一个。 .pages 是苹果 iWork 的格式，qq浏览器内置的文档引擎并不原生支持。我查了官方帮助文档，它支持的是 doc、docx、xls、xlsx、ppt、pptx、pdf、txt 这几类，一共 8 种。.pages 不在这个列表里。这一点其实在“文件管理”页的说明文字里写得很清楚，只是这行小字藏在二级页面，字号 11px，灰蓝色，我前后翻了三遍才注意到。
第二个文件 .dwg 更麻烦。qq浏览器会尝试用内置的“CAD 预览”组件打开它，但那个组件体积有 68 MB，首次使用需要下载。我在设置里关掉了“自动下载插件”，结果就是每次点开都提示“正在准备”，然后卡在 80%。我后来把自动下载重新打开，等了将近两分钟，图纸才勉强显示出来——但尺寸标注全部错位。这跟 新澳正版图 里提到的文件解码方案完全是两种思路，后者走的是服务端转码，本地根本不需要装组件。
第三个文件 .epub 是最让我意外的。它大小只有 1.8 MB，一本书，封面正常，目录也读出来了，但翻到第 12 页时，页面就白屏了。我换成系统自带的阅读器，一切正常。所以问题不在文件本身，而是 qq浏览器的渲染引擎对某些 epub 内嵌 CSS 的兼容性——具体是 flex 布局的段落容器，浏览器版本号 14.8.0 的 changelog 里并没有提到相关修复。
后来我回到设置页，把默认打开方式改成“总是询问”，再点文件，手动选择用 WPS 打开，.epub 的问题立刻消失。这个操作路径其实很短：设置 → 应用管理 → 默认应用 → 文件打开方式 → 选择其他应用。只是入口藏得深，我也是翻了 手机qq浏览器多窗口设置 那篇旧文之后，才意识到同类的功能入口都集中在那一片区域。
“你不需要让一个浏览器打开所有文件。它本来就不是干这个的。”
—— WPS 移动端产品负责人 李昊，2024 年 11 月一次内部分享
我的观点比较明确：qq浏览器的文件打开功能被高估了，至少在 Android 版本上，它的定位更像是“预览”而不是“编辑”。对于 .pages、.dwg、.epub 这类格式，正确做法是把它交给专业应用，而不是在一款浏览器里反复尝试。我甚至认为，产品团队应该把“支持格式”列表从设置页挪到文件打开失败时的提示弹窗里，直接给出建议应用，而不是一句“无法打开”就结束。
另外值得一提的是，我测试的 图49恢复正常使用免费打开49图库免费下载 这个方案里，提到了用系统分享菜单把文件派发给正确的 app，实测确实比在浏览器内部处理要稳定得多。如果你手头有大量格式混杂的文件，我的建议是：先别怪浏览器，先看文件扩展名，再看默认打开方式，最后再考虑换工具。
从 12 月 9 日到 12 月 13 日，我一共记录了 6 次文件打开失败，其中 4 次是因为格式不支持，1 次是插件未下载完整，1 次是渲染兼容问题。这组数字放在一起，其实已经能说明一个问题：大多数“打不开”并不是 bug，而是预期错位。
