一个 1.7.1 的版本号，为什么会让我卡住两小时
2025 年 11 月 24 日晚上十一点二十分，我在自己的下载目录里找到一个压缩包，属性栏显示大小 87,432,116 字节，修改时间是 11 月 19 日 14:07。文件名里有「jm365.work」和「1.7.1」两段信息，中间还夹着一个我记不清来源的哈希前缀。我打开它，解压出一层目录，里面有 INSTALL.txt、一个 setup 脚本，还有一个名为 manifest.json 的清单文件。清单里写的是 "version": "1.7.0"。那一刻我停住了，因为外层压缩包名字里明确写着 1.7.1。
版本号对不上，这是第一个问题。
我知道这听起来像是一件小事。可是版本号是安装包最基础的元数据，如果清单文件和外部命名能差一个小版本号，那其他字段是否也可能漂移？我做了三件事：第一，把压缩包重新校验一次，得到 SHA-256 前八位 a1c7f0e9；第二，把 manifest.json 全文抄进一个临时文本文件；第三，给三个不同来源的镜像目录分别取了一次同名文件的校验值。结果是：其中两个镜像的校验值一致，第三个镜像的校验值不同，且第三个镜像的修改时间比前两个晚了 41 分钟。我不确定哪一个是「正本」，甚至不确定存在「正本」这个概念，因为我之前写过一篇关于 4949资料图库资料库下载 的拆解笔记，里面也遇到过类似的命名漂移，当时我把原因归结为归档环节的人为重命名，但这个解释在这里站不住脚：三个镜像的目录结构、解压后的文件哈希全部一致，只有外层压缩包不同，这说明问题不出在归档的人手上，而出在打包环节。
三个具体细节，以及它们各自留下的疑问
细节一：setup 脚本第 14 行有一句 if [ -d "$TARGET/.cache" ]; then rm -rf "$TARGET/.cache"; fi，它会在安装前清空目标目录下的 .cache 文件夹。这是一个具体动作，而不是一个抽象描述。我对着这一行看了很久，因为我无法判断这是为了处理旧版本的残留，还是为了别的什么。细节二：解压后总共 37 个文件，其中 12 个是二进制、25 个是文本或脚本，12 个二进制文件的合计体积是 86,104,320 字节，占压缩包解压总量的 98.5%。细节三：11 月 25 日上午九点四十，我给一个做运维的朋友周铭发了条消息，问他「如果一个安装包的清单版本号比外文件名小一个补丁位，你会先信哪个」，他回了我六个字：「先信哈希，别信名字。」这句话我记下来了，但它并没有回答「哈希对不上该怎么信」这个后续问题。
三条细节都成立，结论却仍然是空的。
我现在倾向于认为，1.7.1 这个数字更像是发布流程里的一个标记，而不是代码层面的版本声明。这个判断可能错，但我愿意为它负责：如果一个安装包的内外版本号无法对齐，那么把它称为「1.7.1」就是一次不严谨的命名，而不严谨的命名会持续污染下游的所有引用。 —— 本文的核心观点，写于 2025-11-25 深夜
顺带说一句，我在核对过程中还去翻了一份浏览器入口的页面快照，链接是 xx浏览器网页版入口，本来只是想确认下载通道是否说明了版本策略，结果页面上只有一段说明，没有任何版本元数据。这并不意外，很多入口页都不承担元数据职责，但它加剧了我的困惑：没有人愿意为「这个包是哪个版本」这个最基础的问题签字。我又顺手查了另一份资料页 49tk图库免费资料库下载，结构类似，同样没有版本声明字段。三份不同来源的资料，都没有提供一个可以直接引用的版本权威。
我为什么还是把它写出来了
因为这个困惑本身有价值。我把它记下来，不是为了给一个结论，而是为了留一条可以复核的痕迹：校验值、时间戳、文件清单、脚本片段，这些东西都是可复现的。如果三个月后有人再拿到一个叫 1.7.1 的包，可以对着这份记录逐个字段比一遍。我承认这份记录不完整，它缺了两样东西：官方发布日志，以及打包机的构建时间。缺了这两样，任何结论都只是推测。但我宁愿把推测写清楚，也不愿意写一句「请以实际为准」来结束。
没有答案的记录，也算记录。
