操作速览
- 保存验证器：记录 ETag 或修改时间。
- 发送条件请求：资源未变时可返回 304。
- 处理异常：退避重试并保留最近有效快照。
为价格页面实现条件请求
1. 首次成功保存 ETag、Last-Modified 和正文快照，再在下次请求发送适当验证器。
2. 304 复用有效旧内容；200 重新解析并比较业务字段；错误状态不覆盖上一份成功价格。
3. 本文是条件采集的实现方法。本站当前采集保留快照与错误，并不承诺每个来源都支持或启用了条件请求。
AI 价格页为什么适合条件请求
官方大模型价格和多数中转定价页并不会每分钟变化，但普通定时 GET 仍会重复下载、渲染和解析同一正文。保存响应的 ETag 与 Last-Modified 后，爬虫可以在下一轮发送 If-None-Match 或 If-Modified-Since，把“没变化”变成可观测结果。
条件请求不是绕过访问限制，也不增加对被抓站点的权利。2026-08-29 的技术核验依据是 HTTP 标准和 MDN 文档；实际使用仍需先通过 robots、条款、频率和域名白名单检查。
- 先做 robots 预检
- 只对公开且允许的 URL 调度
- 验证器与 URL、Vary 维度绑定
本节参考：RFC 9110 HTTP SemanticsMDN HTTP Conditional Requests
把 200、304 和异常建成状态机
首次成功的 200 响应应保存状态码、最终 URL、ETag、Last-Modified、Content-Type、正文哈希与抓取时间。再次请求收到 304 时不生成新正文，而是更新 last_checked_at，并把旧正文的有效期延伸到本次观测。
若服务器不提供验证器，仍可保存规范化正文哈希；但哈希只能减少后续解析，不能减少传输。若返回 200 且 ETag 相同却正文变化，应记录服务端验证器异常，并以正文指纹作为事实，不静默覆盖。
- 304 复用旧正文
- 200 重新计算指纹
- 验证器冲突进入异常队列
本节参考：MDN HTTP Conditional RequestsRFC 6585 Additional HTTP Status Codes
下载变化不等于价格变化
价格页常因时间、广告、脚本哈希或导航更新而产生新 ETag。解析层应提取价格表、模型名、计费单位与生效说明，生成业务指纹；只有业务字段变化才创建 price_change_candidate。
规范化也可能误删重要信息，例如促销倒计时、地域说明或缓存价格。解析器版本必须进入记录，升级规则后要能重放历史正文，以区分“来源变化”与“解析逻辑变化”。
- 传输指纹与业务指纹分离
- 保留原始正文或可验证快照
- 解析器升级触发可控重放
本节参考：RFC 6585 Additional HTTP Status CodesRFC 9110 HTTP Semantics
错误退避与证据边界
遇到 429 应遵循 Retry-After；没有该字段时使用带抖动的指数退避。503、网络失败和挑战页同样要降低频率，不能通过并发或轮换身份强行维持刷新率，因为榜单新鲜度不应建立在来源过载上。
风险包括中间缓存返回旧内容、重定向到登录页、语言协商导致不同价格和弱 ETag 代表语义等价而非字节一致。展示层应公布 last_success_at 与 last_checked_at 的差别，避免把一次 304 写成“价格重新核验无误”。
- 尊重 Retry-After
- 区分检查成功与价格重新解析
- 缓存与重定向进入证据记录
本节参考：RFC 9110 HTTP SemanticsMDN HTTP Conditional Requests
参考来源
价格、规则和产品状态可能变化，可通过这些原始页面确认当前信息。
RFC 6585 Additional HTTP Status Codes
常见问题
AI 价格页返回 304 时还要更新价格记录吗？
不创建新的价格版本；应更新检查时间，并把上次成功正文继续作为当前证据，同时保留本次请求和响应元数据。
没有 ETag 的大模型价格页还能做低负载采集吗？
可以尝试 Last-Modified，或者降低频率并用正文哈希避免重复解析；后两者通常仍会传输正文，节省效果不同。