WhatsApp网页版

构建指纹的第一手信号

■ 版本变更最先体现为主脚本的文件名摘要变化，界面文案的改动通常滞后数日才出现。■

如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 如果你也在处理WhatsApp网页版，这篇可以顺手对一下。 相关的坑WhatsApp网页版 里列得比较细，可以对照看看。 顺便一提，WhatsApp网页版 讲的是另一个容易忽略的点。

每次构建都会改变主脚本的文件名摘要，这是最可靠的一手信号。

摘要变化后，服务端会保留旧构建一段时间以兼容缓存。

因此同一时刻，两个构建可能同时在跑。

这种并行属于正常状态，并非灰度策略的例外。

判断是否换版，比对摘要比看界面可靠得多。

协议字段调整的兼容窗口

■ 协议调整只向后兼容一个窗口，超出窗口的旧构建会被静默降级为只读，不报错。■

字段增减通常不改接口路径，只改字段的必填性。

旧构建缺少新字段时，服务端按默认值补齐，请求照常完成。

一旦字段语义变更，旧构建的请求会被判定为语义错误。

此时界面不报错，只是部分操作长期处于等待状态。

用户感知到的卡顿，多是这类静默失败累积的结果。

强制重载取得新构建，通常是最快的恢复路径。

灰度切分与回滚的实质

■ 灰度按区域与账号双维度切分，回滚只回配置不回构建，所以旧问题可能原地复现。■

切分先按区域后按账号，两者叠加形成覆盖矩阵。

同一区域的账号可能落在不同分组，表现为同城不同表现。

回滚动作通常只调整分组配置，已下发的构建不回收。

构建残留带来一个副作用，回滚后旧缺陷仍可能被触发。

判断是否完成回滚，看入口可见性而非版本号。