旧版本客户端月中停止采集？同步标志语义变更的版本偏差
浏览器扩展的「人群资产」采集功能升级后，客服收到反馈：部分用户月中点开人群资产提示「已是最新」，数据却停留在月初——没升级的旧版扩展不再采集了，要到下个月 1 日才自己恢复。
在开发 电商数据采集工具 时遇到此问题——一站式电商运营解决方案，从数据采集到智能分析；采集判定标志由服务端下发，新旧版本扩展共用同一张服务端表。
TL;DR
新版本给服务端已有的布尔标志 is_current_month 赋了新语义（当月采集窗口已覆盖），未升级的旧版本按旧含义把它读成「数据已是最新」，幂等判断被短路 → 月中停止采集。这不是要修的 bug，而是 version skew（版本偏差）：同一字段、两种解读。影响有自然自愈边界（次月标志翻 false）；处置 = 提醒升级 + 服务端 upsert 幂等免回滚；预防 = 语义变更必须换新字段。
问题现象
新版扩展采集：写入当月行，is_current_month = true
旧版扩展续采：读到当月行 → 命中「up-to-date」判定 → 中止采集
用户视角：月中点「人群资产」→ 提示已是最新，数据停在月初
次月 1 日：is_current_month 翻 false → 旧版恢复采集（自愈）
诡异之处在于：服务端数据完全正确、新版扩展工作正常、旧版扩展代码一行没改——出问题的只是「旧版读到新版写的行」。
根因
经典的 version skew。标志的名字没变，含义变了：新版本的语义是「当月窗口已覆盖」，旧版本按它自己的历史语义把同一行解读成「数据已最新」，于是按设计正确的幂等判断（已最新 → 不重复采集）短路了整个采集。判断逻辑双方都没错，错的是让两种语义共用一个字段。
浏览器扩展（以及一切客户端）的版本分布不受服务端控制：发布新版后，新旧版本并存是以周计的常态。任何「服务端字段含义」的调整，读方都包括所有历史版本——这和 feature flag 的经典教训同构：复用旧 flag 承载新含义，读方按旧含义行动。
解决方案
当期处置：提醒升级 + 幂等免回滚
发布含新采集逻辑的版本时，明确提醒用户升级——旧版本在当月内不会自己恢复。服务端与数据无需回滚：采集写入是 upsert 幂等，新旧版本交错写入不产生脏数据，次月标志翻转后自动对齐。
长期预防：语义变更换新字段
把「窗口语义」从布尔标志迁移到带明确窗口的新字段，旧客户端不认识新字段就不会误读：
// 反例：复用旧标志承载新语义
{ "is_current_month": true }
// 正解：新语义用新字段，窗口显式、可比较
{ "collected_window": "2026-08", "source_version": "2.3.0" }
幂等判断键与业务语义从此解耦：旧版按旧字段判断、新版按新字段判断，互不越界。
设计原则：给每个标志找自愈边界
标志优先绑定自然时间边界（月、天）而不是「最新」这种绝对语义。本例月翻边界把最坏影响锁定在一个月内；如果没有这种边界，skew 的影响是永久的，只能靠发版修复。
注意事项
- 客户端版本分布不受你控制，服务端字段的任何语义变更都要按兼容性变更对待：枚举所有读方，逐个确认解读路径。
- 自愈边界是兜底不是方案——「下个月就好了」不能当长期状态，业务上是否可接受要显式决策。
- 交错期数据安全的前提是写入幂等（upsert）；做不到幂等的采集链路，版本并存期会直接产生重复或冲突数据。
- 扩展采集链路调试时先隔离生产数据，见 Chrome 扩展采集加 DRY-RUN 模式。
常见问题
feature flag 的最佳实践有哪些？
一个标志只承载一种语义；需要新语义时新增字段而不是复用旧标志；标志绑定明确的时间窗口或版本号；改语义前枚举所有读方（尤其未升级的旧客户端），确认它们不会把新值按旧含义解读。本例的停采就是复用旧标志的直接后果。
服务端字段如何做到向后兼容？
只增不改：已有字段的含义、类型、判定行为保持稳定，新语义用新字段表达，旧客户端读到不认识的字段应当安全忽略。字段名字没变但含义变了，对所有存量读方来说就是一次破坏性变更。
旧版本客户端读到新语义数据怎么办？
三步：把影响限定在有自愈边界的时间窗口内（如自然月翻转后自动恢复）；发布新版本时主动提醒升级，缩短并存期；服务端写入保持 upsert 幂等，让新旧版本的交错写入可以安全混合，不回滚、不清洗。