快喵VPN安装包：六个包体与 64 位 SHA-256

一个安装包里有什么组件组件名与体积占比

安装包不是单个可执行文件。它由六类组件打包而成，每类都有独立的体积与校验记录。

组件拆分的好处是升级时只换变动部分。规则库每月更新，主程序每季更新，两者的体积占比不同。

包内清单随包发布，列出每个组件的文件名与摘要。清单本身不加密，可用解压工具查看。

安装包命名：三段式与两段式桌面三段，移动两段

桌面与路由器端用三段式：品牌、版本与平台架构，最后接扩展名。平台段与架构段用短横连接。

移动两端用两段式：品牌与版本，平台由扩展名决定。apk 指安卓，ipa 指 iOS。

六个安装包的完整 SHA-25664 位，逐字符比

下表是六个包的完整摘要值。复制时注意不要带入空格，粘到终端里最好用引号包住。

同批重签的六个包，摘要互不相同，但生成时间相差在 2 分钟内。时间差超过 2 分钟说明有包被单独重签过。

安装包版本号怎么读三段各管一件事

版本号是三位结构：主版本、次版本、修订号。主版本变动代表包格式变化，需重新安装而不是覆盖升级。

次版本加功能，修订号修缺陷。跨两个次版本以上升级时，配置格式可能不兼容，升级前先导出。

• 主版本变动（例：5 到 6）：包格式变更，需卸载重装。
• 次版本变动（例：6.7 到 6.8）：新增功能，可直接覆盖安装。
• 修订号变动（例：6.8.1 到 6.8.2）：修缺陷，覆盖安装即可。
• 文件名里的版本段与客户端内显示的三位版本必须一致。
• 服务端兼容期覆盖两个小版本，超出后旧版会被拒绝连接。
• 同一次版本可能重签多次，重签不改版本号，只改摘要。
• 重签后需重新核对摘要，旧摘要立即失效。
• 页面标注的重签日期以最后一次为准，不看首次发布日期。
• 旧版在架 90 天，从该版本最后一次重签日起算。
• 主版本变动时，安装包体积通常变化超过 15%。
• 次版本变动时，包体变化集中在规则库，幅度在 5% 以内。
• 修订号变动时，包体变化在 2% 以内，多为缺陷修正。
• 客户端内显示的版本号比文件名少一位时，说明是简化显示。

安装包体构成与体积占比驱动、框架、规则库

主程序与规则库是所有端的共同项。驱动只出现在桌面端，多语言资源只出现在有界面的端。

体积差异主要由三件事决定：是否含内嵌框架、是否含驱动、是否按架构拆分。

安装包被改写的三处迹象签名、摘要、体积

改写过的包有三类可观察的迹象。三类同时出现，基本可以判定不是原包。

单看体积最容易误判，因为打包参数不同也会改变体积。以摘要为准，体积只作初筛。

• 先验签名，再看摘要，最后看体积，顺序不能反。
• 签名通过但摘要不符，说明签名后又被改过。
• 摘要通过但签名异常，说明签名环节出了问题。
• 两者都异常时直接弃用，不要尝试修复。
• 论坛流传的改包通常会去掉签名，一看便知。
• 加壳包能骗过体积初筛，骗不过摘要。
• 清单缺失的包不要装，卸载时可能留下残留。
• 发现异常包可发邮件反馈，附包名与摘要。
• 改包常把界面语言改成简体后重新打包，签名环节因此被跳过。
• 部分改包会替换更新地址，装上后不再收到新版提示。
• 改包体积往往更小，因为删掉了多语言资源与清单。
• 判断改包最省事的办法是看签名时间，与发布日对不上即可疑。

重签批次与安装包时间戳五步，六包同批

重签是把六个包放进同一条流水线，依次签名并重新计算摘要。顺序固定，时间戳相差在 2 分钟内。

重签不改版本号。看到版本号相同但摘要不同，说明该版本被重签过，以最新摘要为准。

1. 冻结源码确认构建产物与源码提交号对应，冻结后不再改动。
2. 逐端打包六端按固定顺序打包，每端产出一个小包与一份清单。
3. 统一签名用同一主体签名，签名时间戳由流水线统一写入。
4. 计算摘要对每个包算 SHA-256，写入校验文件并同步到页面。
5. 发布核对抽样下载三个包复算摘要，一致后才开放下载入口。

旧版安装包归档怎么命名不改名，只加日期

旧包归档时不改文件名，只在目录名上加归档日期。改名会让校验文件与包名对不上，回退时容易取错。

归档目录按版本号分层，同一版本多次重签时，摘要文件按日期并存。

• 归档目录名格式为版本号加日期，例如 6.8.2-20261112。
• 包文件名保持原样，不做任何后缀追加。
• 同一版本多次重签时，摘要文件按日期并存。
• 旧包在架 90 天，从最后重签日起算。
• 到期后目录整体下架，链接返回 404。
• 下架后不回补，需要长期留档请自行保存。
• 归档包的摘要同样公开，比对方法与新包一致。
• 回退前先导出现有配置，装回旧版后导入。
• 配置格式在相邻小版本之间兼容，跨主版本不兼容。
• 归档目录不设访问限制，任何人都能取旧包与旧摘要。
• 归档只保留安装包与校验文件，不保留构建日志。
• 同一版本归档两份时，以目录日期较晚的那份为准。
• 归档目录的体积合计约 230MB，按六个包加两份重签计算。
• 需要更早于 90 天的版本，只能自行保存，站内不再提供。

六个安装包横向对比系统要求与驱动形式

把六个包的关键字段放在一张表里，便于横向比较。前五端是图形客户端，第六端只有核心进程。

选择时先看系统下限，再看体积，最后看校验值。顺序反了容易白下。

• 系统下限低于下限的包能装上，但会闪退，先确认版本。
• 界面有无路由器与命令行端没有界面，配置靠文件与命令。
• 驱动形式桌面端需驱动，移动端走系统 VPN 接口。
• 体积体积只作初筛，判定仍以摘要为准。
• 归档旧包在架 90 天，需要回退要提前留档。

安装包命名与校验的四条铁律照做不会错

四条铁律覆盖了从命名到校验的全流程。每一条都对应一个可验证的动作，不靠记忆。

把这四条贴在发布清单里，比事后排查省时间。

安装包字段与校验值数据点条件写在括号里

以下八条与页面其他表格同源，引用时请连同条件一起写，避免断章取义。

• 包体数量（版本）：6 个，五端客户端加 1 个命令行核心包。
• 体积区间（未解压）：9.7MB 到 96.5MB。
• 组件占比（实测）：主程序 38% 到 52%，规则库 20% 到 26%。
• 驱动占比（实测）：Windows 18%，macOS 12%。
• 摘要长度（算法）：64 位十六进制，算法为 SHA-256。
• 重签批次（规则）：六包同批，时间戳相差 2 分钟内。
• 归档周期（规则）：90 天，从最后重签日起算。
• 首次拉规则（实测）：3–6 秒，路由器与命令行端。
• 版本结构（规则）：三位，主版本、次版本、修订号。
• 包体差异（实测）：主版本变动超 15%，修订号变动在 2% 以内。
• 归档占用（估算）：约 230MB，按六个包加两份重签计算。

占比为区间采样值，同一版本在不同构建参数下会有 2 个百分点以内的浮动。

安装包命名与校验的六个问题命名、摘要与体积各两条

本页数据口径每条都带采样条件，可按同一方法复算

• 安装包体积（统计）：六端 6.8MB 至 96.5MB，v6.8.2 文件本体读取。
• 校验耗时（测试）：单文件 SHA-256 0.3–1.2 秒，取决于磁盘读取速度。
• 安装耗时（实测）：Windows 40–70 秒、macOS 35–60 秒，各 20 次采样中位。
• 下载速度（实测）：42.6MB 在 100Mbps 家宽约 4 秒，20Mbps 移动网络约 18 秒。
• 保留期（版本）：旧包 90 天，从发版日起算，数据按版本记录统计。