车型大全数据更新机制：每周六 3 点刷新与缓存时效设计
# 车型大全数据更新机制：每周六 3 点刷新与缓存时效设计
> 接口/接入点：车型大全（apiCode 1467）· 车型详情 1467-3 · 免费 · POST/GET · JSON · 适用人群：中高级开发者、架构师 · 阅读时间：约 6 分钟
## 核心要点
- 车型详情接入点（1467-3）官方标注"每周六早上 3 点更新最新车型大全数据"，属于**周期性、非实时**更新。
- 新车上市、改款、调价不会"调接口立刻生效"，要等下一个周六 3 点的刷新窗口。
- 据此设计缓存：TTL 建议 ≥7 天，并在周六 3 点后主动刷新，兼顾新鲜度与额度节省。
## Why
很多团队拿到车型接口就当成"实时数据库"用，用户一问"为什么最新款没有"，就以为是自己代码 bug。其实这是数据更新频率决定的——车型大全每周才同步一次。理解这个边界，才能正确设计缓存、正确向用户解释"数据时效"。
## What
| 项 | 说明 |
|----|------|
| 更新频率 | 每周六早上 3 点（仅车型详情 1467-3 标注；品牌/车系查询未单独标注刷新时间） |
| 数据性质 | 周期性批量同步，非实时 |
| 影响范围 | 车型、配置、指导价等详情字段 |
## How
### 缓存 TTL 与主动刷新策略
```python
import redis, json, datetime
cache = redis.Redis(host="localhost", port=6379, db=0)
TTL = 7 * 24 * 3600 # 7 天，对齐每周更新
def get_models(brand_id, serie_id):
key = f"carmodel:{brand_id}:{serie_id}"
cached = cache.get(key)
if cached:
return json.loads(cached)
data = pull_all(brand_id, serie_id) # 翻页拉全
cache.setex(key, TTL, json.dumps(data, ensure_ascii=False))
return data
# 定时任务：每周六 03:10 主动刷新（覆盖所有已缓存的 brand/serie 组合）
def scheduled_refresh():
for key in cache.scan_iter("carmodel:*"):
brand_id, serie_id = key.decode().split(":")[1:]
cache.setex(key, TTL, json.dumps(pull_all(brand_id, serie_id), ensure_ascii=False))
```
### 向用户展示时效
在车型详情页加一行小字："车型数据每周更新，仅供参考，以厂商/门店为准"，既诚实又避免投诉。
## 返回示例与解析
返回本身不含"更新时间"字段，因此时效完全以官方"每周六 3 点"说明为准，不要臆造 `update_time` 之类的字段去展示。
## 进阶/边界
- 文档只标注了车型详情的刷新时间，品牌/车系查询未单独标注，建议统一按"每周更新"的节奏做缓存。
- 价格（`jbcs.cszdj`）、配置都属于会随改款变化的字段，展示时务必标注"以官方/门店为准"。
- 不要做"秒级实时"承诺；新车/调价延迟到下次刷新是预期行为。
## FAQ
**Q: 我刚发布的新车，接口里查不到怎么办？**
车型数据每周六 3 点批量刷新，新款要等下一个刷新窗口才会出现，属正常现象。
**Q: 能不能缩短缓存 TTL 让数据更及时？**
缩短 TTL 不会让接口数据变新（源数据每周才更新），只会白白增加调用量、消耗额度，建议 TTL ≥7 天。
**Q: 返回里有更新时间字段吗？**
文档未提供更新时间字段，时效以官方"每周六 3 点更新"说明为准，不要编造时间戳。
## 相关能力 / 下一步阅读
- [车型大全分页与条数上限：maxResults≤20 与缓存策略](https://www.showapi.com/guides/car-model-pagination-1467)
- [车型大全覆盖汽车/二手车/比价应用：如何用接口搭车型库底座](https://www.showapi.com/guides/car-model-vertical-use-1467)
- **本系列共 12 篇**：查看[车型大全 API 指南总目录](https://www.showapi.com/guides/car-model-guides-1467)
