一、那个文件夹里有 1,247 个文件，我一个也叫不出名字
先把这个场景说清楚。上周二晚上十一点，我在家里那张铺满线材的桌子上，把一块 2019 年换下来的 320 GB 笔记本硬盘接上读卡器。目标很简单：把还能用的照片拷出来，然后把盘格式化掉。结果在 Users/jiangwan/AppData/Local/QQBrowser/User Data/Default/Cache 这个路径下，我看到了一个从没认真看过的目录，浏览器缓存里塞着一千多个没有扩展名的文件，大小从 40 KB 到 380 MB 不等，加起来逼近 9 GB。我随手改了其中一个 180 MB 文件的后缀为 .mp4，双击，是 2019 年 11 月某场线上讲座的录屏，画面里讲课的人还在翻 PPT。那一刻我意识到，这些所谓「qq浏览器的视频」，其实是我七年里无意识留下的一堆影像碎片，而我从来没有给它们做过任何收录与整理。
二、缓存目录不是资料库，但它确实替我们存了东西
我后来花了三个晚上做了个粗略统计，这一千二百多个片段里，能靠重命名直接播放的只有大约 41%，剩下的要么是分片（m4s、ts 之类），要么是文件头被截断、解码器认不出来。这个比例让我有点意外，因为过去我一直默认「浏览器里播放过的视频一定完完整整地躺在本地」。事实并不是这样。qq浏览器的视频缓存更像一个临时中转站：它按字节块切片存储，文件名是哈希值，没有时间戳，没有标题，也没有来源页面。也就是说，它保存了内容，却拒绝保存内容的身份。这一点在整理时非常要命。我不得不依靠文件修改时间、片段时长和偶尔残留的元数据，一帧一帧地反推「这个 3 分 42 秒的片段到底是哪门课的第几讲」。整理到第三天，我才承认这件事的本质不是技术问题，而是命名与索引的问题。
为了不让自己陷入纯手工的泥潭，我做了一个很土的对照实验：把同一个缓存目录分别用三个思路去重建索引，一是按修改时间排序后人工抽帧比对，二是写脚本读取 MP4 的 moov 原子提取时长与编码信息，三是直接依赖浏览器自身导出的历史记录做交叉验证。前两种方法加起来花了大约六个小时，重构出了 617 条可辨识记录；第三种方法在十分钟内给出了 300 多条带标题的条目，但其中至少有两成已经打不开。这个结果说明，索引和文件本体在浏览器缓存里是两条平行线，任何一次清理缓存的动作都会让它们彼此脱钩。
三、收录的三条线：来源、时间、可播放性
在我目前的整理框架里，一条「qq浏览器的视频」记录至少要挂上三个字段才算合格：来源页（哪一次浏览、哪个域名）、时间（缓存写入的时间，而不是我复制出来的时间）、可播放性（能否在标准解码器下直接播放）。这三条线看起来简单，但它们背后对应的其实是三个不同的技术层次。来源页依赖浏览器历史与缓存索引之间的关联，时间依赖文件系统的元数据，可播放性依赖封装格式是否完整。我遇到最典型的一种坏情况是：一个 87 秒的片段，来自某教育站点的试听课，元数据完整、时间清晰，但文件头缺失了 12 个字节，任何播放器都放不出来。这种「身份齐全、身体残缺」的片段，恰恰是最难判断要不要收录的。
我的观点：绝大多数所谓「浏览器视频下载工具」把重点放错了地方。它们热衷于教你怎么把缓存文件改成 MP4，却几乎不谈索引。可真正让这些片段变得有价值的，从来不是能不能播放，而是能不能被检索。一个能播放但无名的文件，价值接近于零；一个暂时打不开但知道它来自哪里、什么时候留下的片段，反而可以被修复、被重新定位。我甚至认为，浏览器厂商应当默认把缓存索引单独导出成一份可读的清单，而不是让用户去和哈希文件名搏斗。
四、一个具体的反例：周岚的 4.3 GB
为了验证我的判断，我请同事周岚把她笔记本上的浏览器缓存也导出来看了一遍。她做纪录片剪辑，电脑上常年开着十几个标签页，缓存目录有 4.3 GB。我们俩坐在会议室里，用一台旧投影仪逐个试播放，试到第 29 个文件时，她突然说：「这个是我去年在泉州拍的那段空镜，我当时在浏览器里预览过一遍就关了。」那个片段只有 1 分 08 秒，36 MB，文件头完好，但没有标题。她说如果当时没有我在旁边帮她按时间排序，她大概永远不会再想起它存在过。这个细节让我确认，收录这件事的价值不只在技术侧，它其实是一种对抗遗忘的动作，只不过发生的地点是缓存目录，而不是相册或云盘。
顺便说一句，如果你只是想先把浏览器端的事情理顺，比如怎么在网页版里正常播放和保存，我此前整理的两篇笔记可以对照着看：一篇讲qq浏览器网页版怎么弄，另一篇讲遇到跳转异常时qq浏览器想要打开应用的处理路径。它们不解决归档问题，但能帮你把「视频到底在哪一层被留下」这件事想明白。
五、还有一堆我没想明白的问题
写到这儿，我必须坦白，这篇文章不是一个结论，而是一份问题清单。第一个问题：浏览器缓存的片段在法律与伦理上算什么？如果我看过的是一段付费课程，缓存里留下的那 87 秒，是我有权保存的「观看痕迹」，还是不该被留下的副本？第二个问题：如果我想长期归档，应该把片段连同索引一起打包，还是只保留索引、让片段随缓存一起消失？第三个问题更实际：有没有一种格式，能让「浏览器缓存里的一段视频」在十年后仍然可以被定位、被播放，而不依赖任何一家厂商的目录结构？我暂时都没有答案。我目前的做法是笨办法：把可播放的片段转成标准 MP4，把不可播放的片段连同哈希名、时间、来源页一起写进一张 CSV，两份东西放在同一个目录下，用同一个编号前缀。编号从 JQ-0001 排到 JQ-0617，正好对上前面统计出的可辨识记录数。至于这套办法能不能撑过下一次系统重装，我不知道。
整理间隙我翻到一条旧帖，讲的是浏览器缓存文件的另一种用法，标题叫474747浏览器打开一百度网。里面提到的思路和我的笨办法方向相反：它更在意入口，我更在意出口。两种思路放在一起看，反而把「qq浏览器的视频」这件事的边界照得更清楚了一点——它既不是一个封闭的下载器，也不是一个可靠的仓库，它只是我们浏览行为的一个副产品，需要有人愿意蹲下来，一个一个地把它们认出来。