那天晚上
从 17c.17.17.c起草入口快速登录入口 的一条回帖说起
我是在 3 月 29 日 23:41 点开那个帖子的，用户名叫「砖头与茶」，2009 年注册，回帖里贴出一张 1024×768 的截图，贴着 3.7.2 的安装向导第一屏。我盯着那张图的标题栏数了三遍日期：2019 年 6 月 12 日。这和我手头存档的安装包签名日期差了十一天，够我把整晚睡意耗光。
2026-03-30•核查
正文：一次关于 3.7.2 的核查
这篇文章比平常长，因为证据链确实需要这么长
细节一
签名日期 2019-06-12 与 2019-06-23 之间那道缝
我把两种说法都记在纸上：旧的帖子写 6 月 12 日，我本地归档里的安装包属性写 6 月 23 日。随后我做了件笨事——把两个文件都解包，逐个比对 DLL 的时间戳，一共 47 个文件，其中 46 个时间一致，只有主程序晚了十一天。差异只出现在编译那一环，说明这更像同一次源码的两次构建，而不是两个版本。这个结论让我松了口气，也让我更谨慎。
2026-03-30•时间戳比对
细节二
邻居老周的一句话，把我从「日期迷信」里拉出来
第二天上午我去楼下修打印机的老周那儿取纸，他扫了一眼我手机上的版本号，说了句「你这个不是发布日期，是打包时间吧」。他在 2013 年到 2017 年之间做过一阵内网软件的打包，这句话挺关键：很多归档站把编译日期当成发布日期，于是用户下载到的「历史版本」其实是同一天不同时刻的产物。我回去翻了 12 个版本目录，有 4 个存在同样的错位。
2026-03-31•旁证
细节三
3.7.2 安装包大小 38.4 MB，比前一个版本只多了 0.6 MB
我顺手记下体积：38.4 MB，前一版 37.8 MB。0.6 MB 的增量不足以塞进一套全新的隐私模块，这也在侧面印证了「同一源码两次构建」的判断。为了不让自己跑偏，我把体积、文件名、哈希前八位整理成一张表，放在 `/2026/11/89752.html` 那张旧版本索引的旁边做对照。做完这些，凌晨两点四十，我泡了杯茶，坐回电脑前继续。
2026-03-31•体积核对
归档方法
为什么我在旧归档里坚持标注「构建批次」这一列
整理历史版本最怕的不是文件缺，是同一个版本号下藏着好几个不同的二进制。我在 `49图库的资料` 那页翻到过一份早期对照表，它只写版本号不写批次，结果被三个不同的下载站各自复制，最后连日期都对不上。于是我给自己定了个笨规矩：四列必填——版本号、构建批次、文件体积、来源截图。这四列凑齐之前，一律不进「已确认」区。冷静讲，这条规矩让我慢了至少三倍，但至少没再出过日期错位的事。
2026-04-01•方法
争议点
说实话，我认为把「隐私开关」当作历史版本的主卖点是偷懒
我不同意那些把某一年版本捧成「隐私最强」的说法。隐私开关在不同构建批次之间变化很小，真正影响体验的是渲染内核和扩展接口的调整；把版本号当成隐私等级的度量，是把工程问题说成了营销问题。这条可能会被骂，但我在核对 2018 年到 2020 年之间 6 个构建批次后，依然这么认为。与其追一个神秘的「最佳版本」，不如把每个批次的变更点写清楚，让人能自己判断。
2026-04-01•观点
旧帖重读
那位「砖头与茶」在 217 条回帖里，后来只回过 3 次
我一页页翻完那 217 条回帖，发现他从第 52 楼之后就几乎不再出现，最后一次是在 2021 年 11 月，只写了半句「后来机器换了，就很少折腾了」。这句话我读了两遍。历史版本下载这件事，真正稀缺的从来不是文件，而是愿意记下「我是怎么弄到这文件的」的人。我在 `手机版qq网页版登录` 这类旧页面里也见过同样的现象：链接还在，来路说明全丢了。丢掉的不是数据，是可信度。
2026-04-02•旧帖
归档边界
哪些东西我不放进「历史版本下载」索引
三条边界：来源不明的二次打包不进，改过签名的安装包不进，跟原始发布说明对不上的进「待查」而不是「已确认」。这条边界是被逼出来的。去年我收过一份所谓 2.9.4 的安装包，解包后多出一个未签名的插件目录，我只能把它单独放进观察区，标上日期 2025 年 10 月 4 日。从那以后，我对任何「看起来很干净」的安装包都多问一句：你的来源截图呢。
2026-04-02•边界
每周更新
4 月第一周的更新：补进 2 条批注，撤回 1 条旧结论
这周的更新量我说实话：很小。补了 2 条批注，撤回 1 条关于 2.6.0 发布日期的旧结论，因为原始帖的截图被证实是 2022 年重传的。撤回这件事比新增重要，我宁愿每周只动三行，也不愿意让索引里留着一个看起来精确但站不住的日期。每周更新的意义就在这里——不是数字变大，是错的地方变少。这个态度我会一直写下去。
2026-04-03•周更
工具
我用的三样东西：哈希、时间戳、一支 0.5 mm 的笔
哈希工具就不多说了，取前八位足够判断是否同一文件；时间戳我用系统自带的属性面板，能看创建、修改两组；那支笔用来抄写对不上的数字，因为手写一遍比复制粘贴更容易发现自己看漏了哪一位。4 月 3 日下午我抄了 11 组哈希，抄到第 7 组时才发现前六组里有一组的末位写反了。工具越简单，越容易暴露自己的粗心。
2026-04-03•工具
关于我
站点维护者
江晚
我是江晚，做版本归档这件事到今年是第六年，主业是做企业内网的软件分发和维护，副业就是维护「私密浏览器历史版本下载」这个站点。开始做它是因为 2020 年一次内网回滚，我需要一个 2019 年的旧安装包，翻遍能找到的下载站，十几个链接里有九个是二次打包的，剩下一个连版本号都标错了。那天下午我在办公室待到了七点半，把能找到的每一条来源都标上日期，从那之后这个站就慢慢长成了现在这样。
我做这个站的方式很笨：先抄来源，再标日期，最后才写版本摘要。每条记录都尽量带上原始截图的时间、文件体积和至少一处旁证；对不上的就放进「待查」，绝不用一句模糊的话把它糊过去。我不追求收录数量，追求的是你点开每条记录时，能看到我是怎么判断的。
如果你也在找某个具体的旧版本，欢迎把版本号和你能记得的来源线索发给我，我会一条条核对，核对结果照样公开，包括我判断错的部分。
—— 江晚，写于 2026 年 4 月 4 日
今天看到的一句话
引用区Quote of the day
「归档不是把文件堆在一起，是替每一个文件记住它从哪来。」—— 出自 2019 年 8 月 17 日《旧档》杂志第 14 期，作者署名「阿梧」，第 27 页，一篇讲个人数字档案整理的短文