轮询状态遇到 304，怎样用 ETag 保留正确的本地副本

条件GET收到304 Not Modified时，应复用与该验证条件对应的本地表示，不把空响应体当成新的空状态。ETag是表示的验证器，不能按数字大小猜版本新旧；本地根本没有副本时，304不足以重建状态，应补一次不带条件的GET并记录异常。

环境和证据范围

以单一状态资源、单一表示的离线序列举例，不处理完整HTTP缓存规则，也不测试代理。真实缓存还受Cache-Control、Vary、鉴权和内容协商影响。本文只面向只读轮询，不将条件缓存套到控制写请求，更不替设备决定刷新频率。

核对顺序

1. 第一次200时保存body及ETag，副本的键应包含完整目标和影响表示的请求条件。不同设备、账户或语言的body不能混放到同一个“最近状态”变量中。

2. 下一次发If-None-Match使用服务端给出的完整标签，不去掉引号，也不把弱标签前缀随意删除。收到304后复用已有body，同时按规范和文档更新适用的响应元信息。

3. 当200带新body和新ETag时原子替换副本，避免标签已变而数据仍旧。若304时没有对应副本，应记录“缺副本需重取”，禁止把空body反序列化成null后覆盖界面。

4. 把“本地刚验证过”与“设备刚采样过”分开。304可以更新验证时间，但不应擅自改写body里的采样时间；设备长期没有生成新采样时，数据仍可能陈旧。

可复算的输入与预期

合成序列为200带标签v1和值10、304、200带标签v2和值12、304。输出副本值10、10、12、12；另一组从304开始，输出“缺副本需重取”。脚本检查的是副本切换，没有生成真实请求头或验证HTTP缓存有效期。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 resource_key、request_if_none_match、response_status、etag、cached_value、sampled_at、validated_at。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

304不是通用心跳成功码，也不能证明传感器刚更新。若所有请求都返回200，可能是ETag变化、请求条件不匹配或设备根本不支持；若一直304，先看源数据更新时间和资源内容，不要单纯提高轮询频率。ETag的具体生成算法不由客户端猜测。

交接给开发者的材料应包含资源键、标签保存位置、条件请求、无副本恢复流程和缓存清除入口。现场还要验证网络中间缓存是否参与，是否有多个资源误共用标签，并保留200与304相邻两次响应的完整脱敏头部。

基础背景可看孪生数据的实时刷新策略：轮询、订阅与降频怎么定。空响应的另一种语义可对照接口返回 204 却报 JSON 解析错，怎样处理没有响应体。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§8.8.3 ETag、§13.1.2 If-None-Match与§15.4.5 304

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。