快喵VPN 更新记录：八条带日期的版本条目

§ 01 · 怎么读这条记录

记录只写会改变行为的事

本页八条记录覆盖 2026 年 7 月至 11 月。每条写清日期、影响哪几端、包体变化，不写界面微调与内部重构。

八条记录对应八个版本，最新一条是 4.7.2（2026-11-04）。记录按日期倒序排列，每条都有独立锚点，可直接引用。

判断标准只有一条：这项变更是否会让用户的行为发生变化。会让用户改设置、改操作、改预期的写进来；纯界面调整不写。因此本页条数少于完整发布说明。

三种记录性质的区分

• 稳定版：只修问题，配置格式不变，可直接覆盖安装。
• 次版本：可能改接口或配置格式，升级前应导出配置。
• 本页没有归档版记录，归档版只在旧系统页面出现。
• 三条区分与其他页一致，判断方法也相同。
• 记录里的包体变化是相对上一个版本，不是相对首发版本。
• 若某端包体未变，说明该端未参与本次发布。

一条记录包含的四个部分

每条记录有四个部分：版本号与标题、发布信息与摘要、改动条目清单、升级建议。四部分按固定顺序排列，扫一眼就能定位到自己关心的那段。

为什么摘要放在第二条

摘要放在标题之后、条目之前，是为了让只想快速判断的人读完一行就够。要细节的再往下看条目清单，不关心的可以直接跳过。这种结构比把摘要埋在最后更省时间。

引用记录时的写法

每条记录都有独立锚点，形如版本号里的小数点换成短横线。引用时带上版本号与日期，例如「v4.6.0，2026-09-23」，比只写版本号更不容易被误读成其他版本线的记录。

记录不写实现细节

条目写的是行为变化与可观察的结果，不写内部实现。例如「同步改为增量下发」只说明体积与失败率的变化，不解释差分算法本身。需要实现层面的内容不在本站范围。

找不到某条改动时怎么办

先确认版本号是否在本页覆盖的区间内。本页从 2026-07-29 的 4.4.0 起记录，更早的版本不在范围内。其次确认改动是否属于界面类，那类改动按规则不写。两者都不是时，按页脚邮箱反馈具体版本与现象。

§ 02 · 2026-11-04

v4.7.2 · 五端统一到同一份配置快照格式

发布日期 2026-11-04，性质为稳定版，影响范围五端全部。五端统一到同一份配置快照格式，Android 端补上按应用分流，Linux 端命令行新增 kuaimiao status 子命令。

这一版改了什么

• 配置快照格式在五端统一，此前 Android 与 iOS 用的是裁剪过的版本，字段名与桌面端不一致。
• Android 端补上按应用分流，采用排除式实现，新装应用默认接管。
• Linux 端命令行新增 kuaimiao status 子命令，输出连接状态与流量统计。
• Windows 端安装包签名换成带时间戳的方式，重装时不会再提示证书链问题。
• 包体变化：Windows 118.6 MB（+0.9）、macOS 96.2 MB（+0.4）、Android 42.8 MB（+1.1）。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。稳定版只改局部代码，包体增幅一般控制在 1.5 MB 以内。

要不要因为这一版升级

当前推荐版本，新装设备直接装这一版。已在旧版的设备建议升级，因为配置快照格式在这一版统一，跨端一致性问题基本消除。

五端全部稳定版2026-11-04

§ 03 · 2026-10-21

v4.7.0 · 桌面端窗口合并为单进程

发布日期 2026-10-21，性质为次版本，影响范围Windows / macOS。Windows 与 macOS 的窗口合并为单进程，常驻内存下降 11 MB，版本号第二位进一位。

这一版改了什么

• macOS 的界面进程与网络扩展合并为一个进程组，常驻内存 87 MB 降到 76 MB。
• Windows 仍保留两个进程，但托盘进程的内存占用下降 4 MB，合计 84 MB。
• 单进程结构带来的副作用是界面关闭后网络服务继续运行，与之前的菜单栏行为一致。
• 该次发布不改配置格式，旧版 4.6.x 可直接覆盖安装。
• 包体变化：Windows 118.6 MB（+1.2）、macOS 96.2 MB（+0.7）。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。次版本通常伴随结构性改动，包体增幅比稳定版更大一些。

要不要因为这一版升级

次版本，需要先导出配置再升级。若不在意新增能力，可以停在前一个稳定版，但要注意后续版本可能要求更高的配置格式。

Windows / macOS次版本2026-10-21

§ 04 · 2026-10-07

v4.6.3 · 移动端后台存活与小组件

发布日期 2026-10-07，性质为稳定版，影响范围Android / iOS。iOS 端小组件支持一键开关；Android 端在 8 GB 机型上后台存活由 46 分钟延长到 3 小时以上。

这一版改了什么

• iOS 小组件放在主屏，点一下即可开关连接，不需要打开主应用。
• Android 端把前台服务的优先级调高，8 GB 机型实测存活 3 小时 14 分。
• 4 GB 机型收益有限，实测从 46 分钟延到 2 小时左右，仍受系统回收策略约束。
• 本次只改移动端构建，桌面端与 Linux 端的包未变。
• 包体变化：Android 42.8 MB（+0.6）、iOS 58.4 MB（+0.5）。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。稳定版只改局部代码，包体增幅一般控制在 1.5 MB 以内。

要不要因为这一版升级

稳定版，只修问题，配置格式不变，可直接覆盖安装。若当前版本没有遇到该记录描述的问题，也可以延后升级，不影响使用。

Android / iOS稳定版2026-10-07

§ 05 · 2026-09-23

v4.6.0 · 同步改为增量下发

发布日期 2026-09-23，性质为次版本，影响范围五端全部。配置同步载荷改为增量下发，单次同步体积从 42 KB 降到 6.8 KB；Linux 端加入 aarch64 构建。

这一版改了什么

• 规则集按行差分，只传变化的行与校验值，单次同步体积降到全量的 16%。
• 弱网失败率从 4.1% 降到 0.6%，测试条件为丢包 3% 与延迟 180 毫秒。
• 配置文件格式从 v2 升到 v3，旧版客户端读到 v3 会拒绝同步而不是报错。
• Linux 端新增 aarch64 构建，树莓派 4 及以上可直接使用。
• 包体变化：Linux 88.7 MB（新增 arm64 84.3 MB）、其余端基本不变。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。次版本通常伴随结构性改动，包体增幅比稳定版更大一些。

要不要因为这一版升级

次版本，需要先导出配置再升级。若不在意新增能力，可以停在前一个稳定版，但要注意后续版本可能要求更高的配置格式。

五端全部次版本2026-09-23

§ 06 · 2026-09-09

v4.5.4 · 修复 macOS 15 菜单栏图标消失

发布日期 2026-09-09，性质为稳定版，影响范围Windows / macOS。修复 macOS 15 下菜单栏图标偶发消失；Windows 端安装包签名换成带时间戳的 EV 证书。

这一版改了什么

• macOS 15 的系统更新重置了扩展授权，导致菜单栏图标在授权失效后不显示。
• 修复方式是在图标消失时自动重新申请一次授权，并给出明确提示。
• Windows 安装包改用带时间戳的 EV 证书签名，重装时不再提示证书链问题。
• 本次不改配置格式，可直接覆盖安装。
• 包体变化：Windows 118.6 MB（+0.3）、macOS 96.2 MB（+0.2）。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。稳定版只改局部代码，包体增幅一般控制在 1.5 MB 以内。

要不要因为这一版升级

稳定版，只修问题，配置格式不变，可直接覆盖安装。若当前版本没有遇到该记录描述的问题，也可以延后升级，不影响使用。

Windows / macOS稳定版2026-09-09

§ 07 · 2026-08-26

v4.5.0 · 配置文件格式升到 v3

发布日期 2026-08-26，性质为次版本，影响范围五端全部。五端统一为 4.5 版号基线，配置文件格式升到 v3，旧版 v2 配置在首次启动时自动迁移。

这一版改了什么

• 配置格式从 v2 升到 v3，字段名统一为小写下划线风格，此前各端命名不一致。
• 首次启动时自动迁移 v2 配置，迁移后不可回退，需要保留旧格式只能事先导出。
• 五端版本号基线统一为 4.5，此前的版本号在各端之间有细微差异。
• 迁移过程会保留一份 v2 的备份在配置目录，体积约 12 KB。
• 包体变化：五端普遍增加 0.4 至 1.2 MB，主要来自迁移代码。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。次版本通常伴随结构性改动，包体增幅比稳定版更大一些。

要不要因为这一版升级

次版本，需要先导出配置再升级。若不在意新增能力，可以停在前一个稳定版，但要注意后续版本可能要求更高的配置格式。

五端全部次版本2026-08-26

§ 08 · 2026-08-12

v4.4.2 · Linux 提供 rpm 并适配 Wayland

发布日期 2026-08-12，性质为稳定版，影响范围Linux。提供 .rpm 包并加入 Fedora 41 的 Wayland 会话适配，托盘图标改用 StatusNotifierItem 协议。

这一版改了什么

• 新增 .rpm 包，Fedora 与 openSUSE 用户可走包管理器安装。
• 托盘图标改用 StatusNotifierItem 协议，Wayland 会话下不再显示为空白方块。
• 部分桌面环境需要安装扩展才能显示托盘，包内提供说明文件。
• 本次只改 Linux 端，其余四端的包未变。
• 包体变化：.rpm 89.5 MB、.deb 88.7 MB、AppImage 91.2 MB。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。稳定版只改局部代码，包体增幅一般控制在 1.5 MB 以内。

要不要因为这一版升级

稳定版，只修问题，配置格式不变，可直接覆盖安装。若当前版本没有遇到该记录描述的问题，也可以延后升级，不影响使用。

Linux稳定版2026-08-12

§ 09 · 2026-07-29

v4.4.0 · 五端同名构建与命名规则统一

发布日期 2026-07-29，性质为次版本，影响范围五端全部。首次提供五端同名构建，包体统一命名规则为平台-架构-版本；Android 最低系统抬到 9.0。

这一版改了什么

• 包文件名统一为「应用名-平台-架构-版本」，此前的命名在各端之间不统一。
• Android 最低系统从 8.0 抬到 9.0，因为 8.0 的前台服务在回收后无法恢复。
• macOS 改为 Universal 2 单包，不再提供分开的 Intel 与 Apple 芯片包。
• Windows 的 ARM64 构建首次与 x64 同版本发布。
• 包体变化：Windows 118.6 MB、macOS 96.2 MB、Android 42.8 MB、iOS 58.4 MB、Linux 88.7 MB。

包体与体积变化

包体变化为相对上一个版本的差值，各端独立构建，因此同一版本下不同端的增幅并不一致。次版本通常伴随结构性改动，包体增幅比稳定版更大一些。

要不要因为这一版升级

次版本，需要先导出配置再升级。若不在意新增能力，可以停在前一个稳定版，但要注意后续版本可能要求更高的配置格式。

五端全部次版本2026-07-29

§ 10 · 分端记录

把八条记录按端拆开看

同一条记录对不同端的意义不同。按端重新排列一遍，能看清哪一端变化最多、哪一端几乎没有动过。

为什么 iOS 命中最少

iOS 的系统接口在统计期内没有变化，客户端也就没有需要适配的地方。四次命中里三次是界面与提示类改动，一次是小组件。这一端的变更频率低不是被忽略，而是没有可改的空间。

Windows 与 macOS 的六次命中

• 两次资源优化：4.7.0 的进程结构调整，4.5.4 的菜单栏图标修复。
• 两次签名与安装相关：4.7.2 的签名时间戳，4.5.4 的 EV 证书。
• 两次配置相关：4.5.0 与 4.6.0 的格式与同步改动。
• 六次里有四次属于维护性改动，不是新增能力。
• 桌面端命中多，是因为它的进程结构更复杂，可优化的空间也更大。
• 这也解释了为什么桌面端的常驻内存一年内下降了约 20 MB。

§ 11 · 时间线

把八条记录串成一条时间线

单条记录回答「这一版改了什么」，时间线回答「这四个月朝哪个方向走」。两者互补，读法不同。

主线一：包体与架构

四个月里新增了三个构建：Windows ARM64、Linux aarch64、Linux rpm。新增构建意味着覆盖的设备类型更多，代价是发布与测试的工作量成倍增加。这条主线在 4.4.0 与 4.6.0 各推进一次。

主线二：资源占用

两次优化把 macOS 的常驻内存从 104 MB 降到 76 MB，Windows 从 88 MB 降到 84 MB。改法都是调整进程结构，因此都发生在次版本。这条主线在 4.6.3 与 4.7.0 各推进一次。

主线三：一致性

一致性走得更慢。4.5.0 统一了字段命名，4.6.0 改成增量下发，4.7.2 才把五端的快照格式真正统一。三步走了 98 天，中间每一步都会影响同步行为。

• 三条主线的推进都发生在次版本，稳定版只做收尾。
• 包体与一致性会互相牵制：统一格式往往意味着包体增加。
• 资源占用是唯一能单独推进的主线，不影响其他两条。
• 三条主线在四个月里各推进两次左右，节奏均匀。
• 时间线比单条记录更能看出方向，但也更容易漏掉细节。
• 读法建议：先看时间线定方向，再回到单条记录看细节。

§ 12 · 包体变化明细

八次发布里，包体一共长了多少

包体变化是判断改动规模的间接指标。增幅大说明动了结构，增幅小说明只改局部。八条记录的增幅都在 0.2 至 1.2 MB 之间。

三次结构性改动

4.4.0、4.5.0 与 4.7.0 三次发布的增幅最大，都在 0.7 MB 以上。三次改动的共同点是动了进程结构或配置格式，因此代码与资源都有较大调整。其余五次增幅都在 0.6 MB 以内。

「不变」是什么意思

• 不变指该端未参与本次发布，包文件与上一版本字节级一致。
• 未参与发布不等于功能落后，能力差异只体现在新增项上。
• 五端版本号仍会同步更新为同一版本，只是包体未重新构建。
• 因此不能靠版本号判断某端是否真的更新过，要看包体变化这一列。
• 八条记录中共出现 13 处「不变」，集中在只影响一到两端的发布上。
• 累计八次发布后，Windows 包体从首发到当前增长约 3.8 MB。

§ 13 · 记录核对

三条能自查的核对方法

记录里的数字都能与客户端内的显示核对。三条方法不需要额外工具，一分钟内可完成。

方法一：核对版本号与日期

打开客户端关于页，版本号应为 4.7.2，发布日期应显示 2026-11-04。若版本号一致但日期不同，说明装的是同一版本的不同构建，属正常。

方法二：核对包体

在下载中心清单里查自己系统对应的包体，与本地文件的字节数比对。差距超过 1 MB 说明拿到的不是这一版，应先重新下载而不是继续排查。

方法三：核对包体变化

若记得上一版的包体，可与表 2 的增幅对照。差距在一倍以内属正常，因为不同系统下同一改动的编译结果略有差异。

• 三条方法都只依赖客户端内的信息，不需要抓日志或抓包。
• 核对顺序建议从版本号开始，版本不对时后两条没有意义。
• 三条都不通过时，先把系统版本与客户端版本记下来再反馈。
• 记录里的日期均为实际发布日期，不是计划日期。
• 表 2 的「不变」已在上文解释，不要读成包体未增长。
• 核对结论可与各页表格互相印证，数字应当一致。

§ 14 · 记录里的规律

八条记录看下来，三个规律

把八条连起来看，能看出发布节奏的三个规律。规律比单条记录更有用，因为它能预测下一次。

规律一：格式变化约每三个版本一次

4.5.0 与 4.6.0 是相邻两个次版本，但 4.4.x 到 4.5.0 只隔了一次。把时间拉长看，格式变化平均每六个稳定版出现一次，也就是约 84 天。因此升级前备份配置的频率不必太高，但遇到次版本时应默认备份。

规律二：资源优化集中在次版本

• 两次资源优化都发生在次版本，因为这类改动需要调整进程结构。
• 稳定版只做小修，不轻易动进程结构。
• 因此想省内存的用户应关注次版本，不必每个稳定版都升。
• 这也是本页把性质列在表格第二列的原因。
• 资源优化带来的收益通常在 8 至 13 MB，不算大但可累积。
• 累积三个次版本后，常驻内存比一年前低约 20 MB。

规律三：移动端总是跟随桌面端

八条记录里，移动端从未先于桌面端获得新能力，最多同步发布。原因是移动端受商店审核约束，且出问题后取证条件更差。这条规律能用来预测：桌面端发布后两到三天，移动端才会跟上。

§ 15 · 订阅与核对

怎么持续拿到这些记录

记录提供两种获取方式：页面直接查看与 RSS 订阅。两种内容一致，更新同步。

订阅地址

/feed.xml

条目数量

7 条

更新时机

每次稳定版发布后

条目字段

标题与发布日期

历史范围

2026-07 至今

纠错方式

页脚邮箱

三种核对方式

• 直接看本页：每条带日期锚点，可按锚点引用。
• 订阅 RSS：条目里带标题与发布日期，点开回到对应锚点。
• 看客户端内的关于页：版本号与发布日期与这里一致。
• 三种方式的内容应当完全一致，不一致时以本页为准。
• 若发现某条记录的日期与客户端里显示的不同，按页脚邮箱反馈。
• 本页不记录未来计划，只记录已发布的内容。

记录为什么不用「即将发布」

计划会变。商店审核、紧急修复都可能导致时间挪动，写进来反而制造落差。因此本页只写已发生的事，下一次时间靠版本节奏页的推算方法得出，不做承诺。

订阅之外的两个习惯

• 每次升级前把当前版本号与日期抄在备忘里，出问题时能立刻定位跨了几个版本。
• 遇到描述与自己对不上的记录，先核对自己的系统版本是否在支持范围内。
• 两个习惯都不需要工具，但能把排障时间缩短一半以上。
• 记录页不提供下载入口，取包统一走下载中心，避免拿到过期文件。
• 若只关心某一端的变化，按端拆开看第 10 节的分端记录更省时间。
• 记录里的能力变动只写结果，不写实现方式，原理不在本站范围。

§ 16 · 记录问答

六个关于记录本身的问题

以下六问针对「为什么某次改动没写进来」这类疑问。每条答案独立成立。

数据 · 记录相关数字

六个可核对的记录数字

以下六条只涉及记录本身与包体变化，条件写在句子里。

§ 17 · 下一步

接着看哪一页

记录看完之后，剩下的是版本规则、装哪个包、配置怎么同步。

若想知道某次能力变化具体在哪一端生效，回能力对照页看对应行，那里有逐端取值。