快喵VPN 版本号与更新节奏：14 天滚动，42 天一次次版本

§ 01 · 三段版本号

三段版本号各管什么，一次说清

版本号只有三段：第二位管接口，第三位管修复。判断升级风险只需看第二位有没有变，变了就有配置迁移风险。

快喵VPN 当前版本 4.7.2（2026-11-04 签发）。三段数字依次是：第二位 7 表示第 7 个次版本，第三位 2 表示该次版本下的第 2 个稳定构建。第一位在可预见的版本里保持 4，用于大版本换代。

判断升级风险的方法只有一条：第二位变了就先备份配置，第三位变了直接覆盖安装。这条规则在五端通用，不因系统而异。

为什么构建号不对外

构建号是打包流水线生成的内部序号，同一个版本号可能对应多个构建号，只在排障时用于定位具体产物。下载文件名里不带构建号，同步判断也不看它。

三套编号不要混着说

客户端版本、配置格式、同步协议是三套独立编号。客户端版本看三段数字，配置格式只有 v2 与 v3 两代，同步协议 2026 年内只出现过 2 与 3 两个值。混着说会出现「4.7 版的协议是 v3」这类错误表述。

三段之外的第四个数

• 包文件名里的版本号与关于页显示的一致，都是三段，不含构建号。
• 配置格式版本是独立的一套编号（v2、v3），与客户端版本号不同步。
• 同步协议版本又是另一套，4.6.0 起为 2，与配置格式版本无关。
• 三套编号混着说会造成困惑，本页统一用「客户端版本」「配置格式」「同步协议」三个词区分。
• 同一客户端版本对应固定的配置格式与同步协议，不会出现一个版本两套格式。
• 配置格式只在次版本进位时变化，同步协议变化更少，2026 年只变过一次。

版本号怎么看才不出错

• 从关于页读三段数字，不要从安装包文件名猜。
• 比对时逐段比，不要只比第一位：4.6.3 与 4.7.2 的第一位都是 4。
• 第二位不同意味着可能有配置迁移，第三位不同只是修复。
• 同一账号下各端版本不同属正常，不必强行统一。
• 记录版本号时带上日期，便于回退时定位目标版本。
• 企业环境统一版本时按第二位锁定，例如统一在 4.7.x。

§ 02 · 更新节奏

14 天一个稳定版，42 天一次次版本

节奏是固定的：稳定版每 14 天出一次，次版本每 42 天一次。三个稳定版后跟一个次版本，循环推进。

为什么不是每周发

每周发会让用户的升级行为分散，问题样本也随之分散。14 天的节奏能让同一批用户集中升级，崩溃率这类指标才有统计意义。42 天的次版本间隔则是为了让三个稳定版积累足够的修复再动接口。

灰度指标怎么读

只看两个指标：崩溃率与首连成功率。前者高于 0.3% 就暂停，后者低于 97% 也暂停。两个指标都在客户端内上报，不做用户行为采集。

节奏对用户意味着什么

• 每两周会看到一次更新提示，提示可以延后，不会强制升级。
• 每六周会有一次可能需要备份配置的升级，界面会额外提示。
• 紧急修复不占节奏，只在必要时插入，且只影响出问题的那一端。
• 节奏固定带来一个可预期的好处：知道什么时候该检查更新。
• 规律升级能避免版本跨度过大，跨度过大时迁移路径更复杂。
• 节奏不因用户量变化而调整，统计期内八个版本间隔都很稳定。

灰度为什么按平台分

• 桌面端先发两天，因为用户能提供完整日志，便于定位。
• 移动端只能提供截图，因此放在桌面端之后，用桌面端的崩溃率当预警。
• Linux 放在最后，用户量最小但对配置环境最敏感，出问题的复现成本高。
• iOS 受商店审核节奏约束，实际推送时间可能比计划晚 1 至 3 天。
• 灰度比例按用户数而非设备数计算，同一账号多设备算一个用户。
• 暂停推送时已升级的用户不回退，只停止新增推送。

§ 03 · 文件命名

文件名怎么读：平台、架构、版本三段拼起来

十个安装包的文件名遵循同一套规则：平台在前、架构居中、版本在最后。读懂规则就能从文件名反查该装哪一份。

以 kuaimiao-win-x64-4.7.2.exe 为例，四段依次是应用名、平台、架构、版本。macOS 的通用包没有架构段，因为两套二进制在同一个包里。iOS 不提供独立文件名，由商店分发。

为什么文件名里必须有架构

架构不同意味着二进制不同，装错了不会在安装时报错。把架构写进文件名，是让用户在下载前就能判断，而不是装完再排查。Windows 与 Android 各有两种架构，所以各有两个包。

三种命名上的例外

• macOS 通用包没有架构段，因为一个包内含两套二进制，无需选择。
• iOS 没有独立文件名，商店分发时按设备架构裁剪。
• Linux 的 AppImage 不带架构段，但实际构建只提供 x86_64。
• 文件名不得改名：改名后无法反查架构与版本，装错也难以发现。
• 文件名与关于页显示的版本号一致，都是三段，不含构建号。
• 批次内所有包的文件名规则一致，不因平台而变。

§ 04 · 版本记录

最近八个版本，每个都标了影响面

下表是 2026 年 7 月至 11 月的八个版本。记录只写会影响使用的变更，不写界面微调，也不写内部重构。

三个关键节点

第一个是 4.5.0，把配置文件格式从 v2 升到 v3，这是不可回退的一次变更。第二个是 4.6.0，同步改为增量下发，单次体积从 42 KB 降到 6.8 KB。第三个是 4.7.2，五端统一到同一份快照格式，跨端一致性第一次真正做到字段级。

版本记录里的三种性质

• 稳定版：只收修复，配置格式不变，可随时升级，版本号第三位进位。
• 次版本：可能改接口或配置格式，升级前应备份，版本号第二位进位。
• 归档版：停止更新但保留下载，仅供旧系统设备使用。
• 2026 年 8 月至 11 月共 4 个稳定版与 4 个次版本，与计划的 14 天、42 天节奏一致。
• 没有任何一个版本的发布间隔偏离计划超过 2 天。
• 紧急修复在统计期内出现 1 次，只影响 macOS 端。

记录里为什么没有界面改动

界面微调、文案调整、图标替换这类变更不影响使用，写进记录只会稀释重点。判断标准是：这项变更是否会让用户的行为发生变化。会变的写，不会变的不写。

怎么用这张表判断要不要升

• 先看「影响哪几端」这一列，自己不用那一端就可以延后。
• 再看「变更摘要」，出现配置格式、同步协议、驱动这类词时优先升级。
• 最后看当前版本，跨两个以上次版本时先导出配置。
• 三条看完只需一分钟，比逐条读发布说明快得多。
• 记录按日期倒序，最上面一条即当前版本。
• 带日期的完整条目另见更新记录页，那里每条单列并附影响面。

§ 05 · 更新提示

更新提示怎么出现，能不能关掉

更新提示有三个层级：静默检查、界面提示、强制阻断。多数情况只到第二层，第三层只在配置格式不兼容时出现。

为什么会有强制阻断

配置格式 v3 快照在 v2 客户端上无法解析。与其让用户连上后出现空配置，不如在连接前阻断并提示升级。这是唯一会阻断使用的场景，其余提示都可以延后。

延后提示的代价

• 延后 7 天后会再次提示，连续延后三次后不再自动提示只保留入口。
• 延后期间仍可正常使用，但拿不到该版本的修复。
• 安全提示无法延后，因为旧版本超出支持范围时风险随时间累积。
• 强制阻断只能通过升级解除，回退到更低版本会再次触发。
• 企业环境可以用分发策略统一关闭界面提示，但无法关闭静默检查。
• 静默检查只上报版本号，不上报任何使用数据。

更新提示与同步的关系

更新提示不影响同步。同步按字段合并，与版本号无关，因此即使某端长期不升级，只要配置格式仍兼容，同步就继续工作。真正会中断同步的只有配置格式跨代这一种情况。

§ 06 · 更新渠道

三个渠道，差别只在推送时间

渠道不改变包内容，只改变拿到新版本的时间。稳定渠道跟计划走，预发布渠道提前 3 至 5 天。

为什么不做每日构建渠道

每日构建可能出现无法回退的中间态配置，一旦写入就无法用旧版本读取。对普通用户来说，这种风险远大于提前尝新的收益，因此不对外提供。

渠道偏好的同步规则

• 渠道偏好是同步字段之一，但按设备保留，不参与跨端比较。
• 一台设备切到预发布，不会影响其他设备的推送时间。
• 切换渠道后需要手动检查一次更新，客户端不会立即重新拉取。
• 从预发布切回稳定时，若当前版本高于稳定版，会保留当前版本等待追平。
• 渠道切换不改变配置格式，因此没有迁移风险。
• 企业环境统一部署时建议锁在稳定渠道，避免版本分散。

§ 07 · 回退

回退不是降级安装，四个前提

回退到旧版本有四个前提。缺任一项时回退会失败，或回退成功但连不上。

回退的两个失败案例

第一类是没有清理驱动就装旧版：两个版本的虚拟网卡同名，旧版启动时找不到可用设备，表现为点连接无反应。第二类是没有导出配置就回退：v3 快照在旧版里读不出来，界面显示空配置，看起来像配置丢失。

什么时候该回退

• 新版本出现可复现的崩溃，且重启与重装都无效时。
• 新版本移除了自己依赖的能力时，例如某项分流能力被裁掉。
• 设备处于系统边界外，新版无法在系统上运行时。
• 回退的前提是四个条件都满足，缺一项就不建议回退。
• 回退不是长期方案：旧版本不再接收安全修复，风险随时间累积。
• 回退后应记录版本号与回退原因，便于下次判断是否需要再升。

回退后的三个动作

第一，把更新提示关掉，否则客户端会反复提示升级。第二，检查配置是否完整导入，重点看规则条数与快捷键。第三，记录当前版本号与回退日期，下次判断是否需要再升时以这条记录为准。

四个前提里最容易漏的一个

• 最容易漏的是「配置格式没跨代」。多数人只想着卸载与重装，忘了配置已经是 v3。
• 判断方法：在关于页或导出文件里看格式版本，v3 就不能直接回退到 4.5.0 之前的版本。
• 若已经跨代，唯一做法是先导出 JSON、回退、再手工导入，不能依赖同步。
• 导出的 JSON 在旧版里可能有部分字段不识别，导入后会跳过，不算失败。
• 导入后核对规则条数，条数一致即视为成功。
• 跨代回退之后，同步应保持关闭，避免旧版把 v2 快照写回账号覆盖其他设备。

§ 08 · 版本计划

怎么看下一次更新在哪天

发布节奏固定，所以下一次时间可以推算。推算方法只需要两个已知量：上次发布日与间隔天数。

计划与实际的偏差

2026 年 8 月至 11 月的 8 次发布里，偏差都没有超过 2 天。偏差主要来自 iOS 商店审核，桌面端与 Linux 端基本按计划发布。因此推算结果可作参考，不必精确到小时。

三个影响时间表的因素

• 商店审核：iOS 端可能延后 1 至 3 天，Android 商店通常同步。
• 紧急修复：出现时会插入一次额外发布，只动出问题的那一端。
• 节假日：跨长假时可能顺延一次，历史上出现过 4 天顺延。
• 这三个因素只影响推送时间，不影响版本号规则。
• 计划可以推算，但不必依赖：客户端内会提示有新版本。
• 若需要精确时间，以更新记录页的条目为准，那里按实际发布日记录。

§ 09 · 跨版本迁移

跨几个版本升：能不能一次跳过去

跨版本升级看两件事：跨了几个次版本、中间有没有配置格式变化。跨得越多，越应该先把配置导出。

为什么可以一次跳三个次版本

安装器不要求逐版升级，直接从 4.4.x 装 4.7.2 是允许的。原因是配置迁移在首次启动时一次完成，而不是逐版累积。跳过中间版本不会漏掉迁移步骤。

跨版本升级的三步

• 第一步导出配置，导出的是当前格式的 JSON，无论中间跨几个版本都能在升级后对照。
• 第二步覆盖安装，不需要先卸载，安装器会替换文件并保留配置目录。
• 第三步核对字段，重点看规则条数、快捷键与按应用分流名单三项是否与导出前一致。
• 若某项字段条数不一致，用导出的 JSON 手工导入补回。
• 跨三个以上次版本时，建议先在非主力设备上试一次。
• 升级完成后确认版本号，避免安装器因权限不足静默失败。

不能跳过的情况

• 第一位大版本换代时可能需要先升到指定中间版本，具体以发布说明为准。
• 配置格式跨两代（例如从 v1 到 v3）时没有直达路径，只能重装后重新配置。
• 设备系统版本低于新版最低要求时，升级会失败，只能停在旧版本。
• 这三种情况都属少数，绝大多数升级可以一次跳过去。
• 判断方法：看中间是否有两次配置格式变化，有才需要特殊处理。
• 2026 年 8 月至 11 月的版本序列里，只出现过一次格式变化（4.5.0）。

§ 10 · 怎么读发布说明

发布说明里的四类信息，先看哪一类

发布说明通常写得很长，但真正影响决策的只有四类信息。按顺序看完四类，其余可以不读。

为什么前两类必读

前两类会改变设备能不能继续用。最低系统抬高后，旧系统设备会被挡在门外；配置格式变化后，旧版本客户端会拒绝同步。这两类信息一旦漏读，后果要等到安装或同步时才暴露。

后两类怎么按需读

• 能力增减：只看自己每天会用到的功能是否被动过，没动过就可以跳过。
• 问题修复：只看自己是否遇到过该问题，没遇到过可以延后升级。
• 两类信息都不影响安装决策，读与不读都不会导致失败。
• 若时间有限，只读前两类即可做出升级决定。
• 发布说明按版本倒序排列，最上面一条是当前版本。
• 带日期的完整条目另见更新记录页，那里每条单列并附影响面。

三个容易被标题误导的地方

• 标题写「性能优化」时，实际可能只是把某项检测从启动阶段挪到连接阶段，感受不到差别。
• 标题写「界面调整」时，实际可能包含术语改动，会影响你按旧说法找设置项。
• 标题写「修复若干问题」时，具体条目在正文里，不读正文无法判断是否与自己相关。
• 三个地方都不影响是否升级，只影响升级后的预期。
• 遇到这类模糊标题，直接看正文的条目列表。
• 正文条目通常按影响面排序，越靠前影响越大。

§ 11 · 版本问答

八个版本相关的问题

以下八问集中在「要不要升」「升了会怎样」两类。每条答案独立成立。

数据 · 版本相关数字

七个可复现的版本侧数字

以下七条只涉及版本与发布节奏，条件写在句子里，可与表 1 至表 5 对照。

§ 12 · 下一步

接着看哪一页

版本节奏看清之后，剩下的是配置怎么同步、装哪个包、设备够不够。

若要判断自己设备的版本是否还能同步，先看能力对照页的配置同步一行，再看本页的配置格式两代说明。