更新记录：每次变更都要写清旧值、新值与原因

变更记录最常见的失败是写成发布公告：只说“优化了体验”，读者无法判断自己是否受影响。快喵的四条书写规则是：旧值与新值同时给出、影响范围写明平台与等级、回滚条件写清、涉及字段的必须在字段表同步。

四条书写规则

• 旧值与新值并列 例如“探测间隔 15 分钟改为 10 分钟”，而不是“优化了探测间隔”。
• 影响范围具体 写明受影响的平台组合与风险等级，避免用“部分用户”含糊带过。
• 回滚条件明确 标注在什么情况下会回滚、回滚需要多久、回滚后用户侧有什么变化。
• 字段表同步 任何涉及留存字段的变更，必须在同一批次更新字段表与政策文本。

第二条规则最容易被跳过。以“探测间隔改为 10 分钟”为例，它影响的是耗电与判定灵敏度，对长期插电的桌面端几乎无感，对移动端可能带来可感知的电量变化。把平台差异写清楚，比笼统说“优化”更有用。

还有一条实践上的细节：记录里的日期统一使用北京时间，且只在发布完成后写入，不允许预发布。这条规则看似琐碎，却能避免一类常见混乱——提前写好的日期在延期后忘了改，最终读者拿到的是一份时间对不上的记录。

V3.2 于 2026-11-10 发布，覆盖 Windows、macOS、Android 与 iOS 四个平台。核心变化有三：出口层速率窗口与异常隔离细则公开、断开流程的时间预算公开、设备解绑后的哈希保留期由 45 日改为 30 日。第三项属于收紧，因此不涉及回滚兼容问题。

另一处容易被忽略的改动是断开事件的保留期从 120 日缩短到 90 日。这类收紧项在发布说明里往往被写得很轻，但它对可调阅窗口的影响是实质性的：窗口越短，历史行为的可还原程度越低。快喵因此把收紧项与功能项分列在同一张表里，不混在“优化”之下。

为什么这次公开的是约束而不是功能

出口层的具体参数此前只在内部文档里，原因是担心被用来规避限制。实际评估后认为，公开约束带来的可核验收益大于被规避的风险——真正的规避靠的是行为检测，而不是参数保密。这也是本文档把 480 个会话上限写进正文的原因。

• 可核验 读者可以据此判断自己遇到的限速是否在预期范围内。
• 可对比 跨版本对比时，参数变化本身就是判断服务走向的依据。
• 可追责 写进公开文档的约束若被违反，就是明确的偏差而不是“没承诺过”。

风险库 2026-10 版把同名热点的网关指纹比对由 3 项扩展为 4 项，新增 TLS 特征比对。这一改动让同名热点在咖啡厅场景下的命中率从 62% 提升到 81%，同时把酒店与机场的合法门户从 L3 降为 L2，减少了不必要的断流。两项改动方向相反，因此需要分别评估误报。

这次调整还暴露了评估方法的一个短板：命中率与误判率不是此消彼长的关系，它们由不同的阈值控制。把两者放在同一张表里逐项看，才能判断一次调整究竟改善了什么，而不是笼统地认为更准了。

同月完成第 3 轮核验

2026-10-16 完成第 3 轮核验，覆盖 4 个模块、11 项字段与 6 个平台组合，受控连接 200 次。发现 1 项偏差（节点侧转发队列保留 5 秒内容），整改为元数据队列后 7 天复验通过。该偏差已在审计报告页表 3 中登记为 D-05。

• 核验范围 客户端、接入层、出口层与业务库四个模块。
• 新增检查项 节点侧内存检索，用于发现只在内存中短暂存在的残留内容。
• 偏差项 1 项，编号 D-05，整改耗时 7 天。
• 未覆盖 支付链路与供应链，与第 1、2 轮一致。

2026-09-22 的故障演练注入 6 类故障，最长的服务中断为 4.2 秒，全部 6 类故障均未出现明文出站。演练同时暴露了一个设计缺口：网卡异常时客户端会先恢复系统路由再重建隧道，中间存在约 0.3 秒的窗口。该窗口已在 V3.2 中改为先阻断再恢复。

DNS 解析归属上移

2026-09-08 把 DNS 解析归属从 L2 上移到 L1。改动前，处于 L1 状态的会话仍使用本地解析器，实测在 12% 的公共网络样本中存在解析偏离但未被拦截。改动后 L1 即接管解析，代价是解析延迟增加约 12 毫秒，这部分延迟在页面加载中被证明可以忽略。

• 改动前 L1 用本地解析，12% 的公共网络样本出现解析偏离未被拦截。
• 改动后 L1 即接管解析，偏离在进入隧道前即被识别。
• 代价 解析延迟增加约 12 毫秒，页面加载时间变化在误差范围内。
• 回滚条件 若解析失败率高于 0.3%，回退到 L2 接管。

2026-08-14 字段评审通过，留存字段从 6 类 18 项收敛到 4 类 11 项，删除 7 类行为字段的库表列。四天后 V3.1 发布，风险分级由二值改为四级，kill switch 改为仅可手动解除。两项改动叠加后，用户在公共网络下的可见状态从“已连接”变成带等级的“强制保护”或“受限保护”。

字段收敛的另一个后果是恢复了用户对“看不到的东西”的信任：删掉 7 类字段后，账号数据导出页的字段数从 18 项降到 11 项，导出的文件体积也从约 6 KB 降到 3 KB 左右。体积变化本身不是目标，但它让“确实删掉了”这件事变得可观察。

为什么分级改动风险最大

从二值到四级，意味着每一次判定都会产生一个可见状态，而任何一次误判都会被用户直接看到。上线首周的误判率是 7.4%，主要来自机场网络的合法门户被判为 L3。两周内通过把门户识别降为 L2，误判率降到 1.9%。这段过程被写进记录的原因很简单：它说明分级模型需要真实网络数据才能收敛，而不是设计时想清楚就够了。

• 上线首周误判率 7.4%，主要来自机场与酒店的合法门户。
• 四周后误判率 1.9%，通过降级门户识别与增加可信网络标记实现。
• 保留的问题 企业自建 CA 的内网仍会被判为证书异常，需手动标记可信。

快喵的评估分三步：先按影响面把变更分为三类，再为每类设定灰度比例与观察窗口，最后确定回滚条件与回滚耗时。三步都要写进发布单，缺一项不得上线。三类影响面的划分标准是“是否改变用户可感知行为”，而不是代码改动量。

回滚为什么能在 11 分钟内完成

回滚速度取决于配置与代码的分离程度。快喵把判定规则、阈值与算法标识都放在签名配置包里，回滚只需下发上一版配置，客户端在 60 秒内拉取生效，不需要用户重装。11 分钟是含人工确认与灰度验证的总耗时，纯下发环节约 3 分钟。

• 配置分离 规则与阈值不编译进客户端，回滚不依赖重新发版。
• 双版本共存 配置包携带新旧两套标识，切换时不需要中间态。
• 人工确认 A 类回滚需两人确认，避免误触发。
• 灰度先回 先回滚灰度批次，观察 10 分钟后再决定是否全量。

快喵提供三种获取渠道：本页（按日期倒序）、RSS 订阅与客户端内公告。三者的内容一致，差异在于时效与格式——RSS 适合聚合阅读器，客户端公告适合只在需要时查看的用户。本页的每一条记录都可以被单独引用，引用时建议带上日期。

三种渠道里，RSS 的价值在于可追溯：聚合阅读器会保留历史条目的原文，即便某天本站迁移或改版，订阅者本地仍有旧记录副本。这也是为什么每条记录都带独立日期与可引用的标题，而不是把多次更新合并成一条季度摘要。

核对一条记录的三步

1. 定日期先确定记录日期，再对照自己的客户端版本发布时间，判断是否覆盖当前版本。
2. 看旧值新值确认记录是否同时给出旧值与新值；只有新值说明记录不合格，可直接反馈。
3. 查同步位置涉及字段的变更应能在无日志政策页找到对应字段；找不到即为同步缺失。

第三步是本文档体系里最实用的一条：把更新记录与政策文档交叉核对，可以低成本发现“改了代码但没改文档”这类问题。这类问题也是历次核验中出现频率最高的一类偏差。

术语表

灰度

按比例分批放量并观察的发布方式，用于把风险限制在可控样本内。

回滚条件

触发回滚的明确判据，例如失败率超过阈值或投诉超过阈值。

A 类变更

改变用户可感知防护行为的变更，需四批灰度与 24 小时观察。

配置分离

把规则与阈值放在签名配置包而非编译进客户端的设计。

更正记录

对已发布记录错误的补充条目，不修改原文，保证历史可追溯。

同步缺失

代码已改而政策文档未同步的情况，属于最常见的偏差类型。

观察窗口

每批灰度上线后用于收集异常的时间长度。

影响面

一次变更可能波及的平台、等级与用户比例。

读索引时建议先看类型再看日期：同一类型的连续变更往往反映一条工作线的推进，例如八月到十月的三次核验，其偏差项从日志字段迁移到定时任务再到节点内存，这条路径比单条记录更能说明检查深度。

变更索引

自查清单

1. 版本对照确认客户端版本号与本页最新记录的版本一致，不一致说明未更新。
2. 字段对照确认无日志政策页的字段表日期与本页字段变更日期一致。
3. 阈值对照确认公共WiFi防护页的阈值表与本页最近一次阈值调整一致。