选择加速乐 cdn 后如何进行缓存策略与资源版本管理

1. 概览：先明确目标与边界

- 目的：降低回源压力、缩短页面加载时间、可控缓存刷新与快速回滚。
- 边界：静态资源（JS/CSS/图片）优先走 CDN 缓存；动态接口慎用 CDN，或使用边缘缓存策略。
- 操作前准备：在加速乐控制台创建域名、获取 CNAME、API Key（若有）。

2. 接入前的准备工作（控制台与 DNS）

- 账号设置：在加速乐控制台完成域名添加、证书配置（若需要 HTTPS）并记下平台给出的 CNAME 地址。
- DNS 配置：在 DNS 管理面板将要加速的子域（如 static.example.com 或 www.example.com）指向加速乐提供的 CNAME。生效后通过 dig/curl 验证解析是否到 CDN。命令示例：dig CNAME www.example.com 或 curl -I -H "Host: www.example.com" https://CDN地址。
- 回源设置：在控制台配置回源域名/回源协议（http/https）和端口，设置回源白名单等。

3. 基础缓存策略配置（Cache-Control 与 TTL）

- 静态资源推荐：对带版本的静态资源（含文件名哈希）设置长 TTL，如 Cache-Control: public, max-age=31536000。
- 可变资源或首页：对 index.html 等入口文件使用短 TTL 或 no-cache，配合 ETag/Last-Modified：Cache-Control: no-cache, must-revalidate 或 max-age=60。
- 设置请求头：在源站（Nginx/Apache/应用服务器）配置相应响应头，例如在 Nginx 中：add_header Cache-Control "public, max-age=31536000"; 对 HTML 设置特殊配置。

4. 缓存键与缓存路径设计（避免缓存冲突）

- 缓存键原则：通常以完整 URL（含查询字符串）为键。决定是否对 query string 进行缓存区分（控制台通常有开关）。
- 去掉不必要的参数：对于会变化但不影响资源内容的参数（如 utm_*），在 CDN 或回源前进行去除或忽略。
- 路径与扩展名划分：把图片、字体、脚本、样式等分别作为不同缓存策略的规则，便于精细化管理。

5. 资源版本管理（文件名哈希与构建流程）

- 推荐做法：使用文件名哈希（content hash），例如 app.9f3a2b.js，每次内容变化文件名就变。
- 构建工具配置：在 webpack、rollup、vite 中启用 contenthash：output.filename = '[name].[contenthash].js'，并生成资源清单（manifest.json）。
- 引用替换流程：服务器端模板或静态页面在部署时读取 manifest.json 替换引用，保证 HTML 引用的都是已发布版本。

6. Query-string 版本 vs 文件名版本：实际选择建议

- 不推荐将版本放在 query string（如 app.js?v=1.2）作为长期策略，因为部分 CDN/缓存层对 query 参数处理不一致，且不利于长缓存。
- 推荐文件名哈希 + 长缓存策略，配合对入口 HTML 的短缓存或即时刷新（见下文）。

7. 缓存刷新（Purge/Invalidate）与局部更新流程

- 按需清除：在发布新版本时通过 CDN 提供的清除 API（或控制台）提交要清除的 URL 列表或路径模式。示例（伪代码）：POST /purge { "urls":[ "https://static.example.com/app.js" ] }。
- 批量策略：对大量资源发布优先使用基于路径的批量清除（比如 /static/v20260512/*），同时避免逐文件清除造成 API 限额问题。
- 缓存预热（可选）：清除后可以用脚本并行请求关键资源，触发 CDN 回源缓存加速首访。

8. 验证与监测（如何确认缓存生效）

- 验证头部：使用 curl -I 查看响应头，关注 Cache-Control、Age、X-Cache（或加速乐返回的类似头）与 Via。
- 浏览器检测：在 Chrome DevTools 的 Network 面板查看 Response Headers 与 Size/From Disk Cache 信息；对比回源和 CDN 的响应时间。
- 日志与监控：在回源开启访问日志/指标，监控回源命中率、流量变化、错误率，设置告警阈值。

9. 动态内容、API 与边缘缓存策略

- 对于 API 返回动态内容，优先在应用层控制缓存（Cache-Control: no-store / no-cache），或在 CDN 层配置基于 Cookie/Authorization 的不缓存规则。
- 可使用边缘缓存策略（stale-while-revalidate / stale-if-error）在 CDN 支持时降低延迟并提升可用性。
- 对易变但可短时缓存的数据（如排行榜），设置短 TTL（如 30s-60s）并结合回源刷新逻辑。

10. 自动化：将清除与版本管理纳入 CI/CD

- 构建阶段：CI 生成带哈希的静态文件并产出 manifest.json，然后将文件上传到对象存储或直接部署到回源服务器。
- 部署阶段：在部署脚本中调用 CDN 清除 API，清除旧引用或通知 CDN 拉取新资源；示例步骤：1) 上传文件 2) 更新 manifest 3) 推送到主机 4) 调用 purge API。
- 回滚策略：保留前 N 个版本的 manifest 与旧文件路径，出现问题时快速回滚 HTML 引用并再次触发清除/预热。

问：我已经把域名接入加速乐，怎样确保新发布的静态资源能立即被用户获取？

- 答：使用文件名哈希（content hash）发布静态资源，并对这些资源设置长缓存（max-age=31536000）。发布新版本时替换 HTML 中的引用（读取新的 manifest.json），同时调用加速乐提供的缓存清除 API 或按版本路径清除旧缓存，必要时做缓存预热。前端用户会因 HTML 更新而请求新文件名从而获得最新资源。

问：动态接口可以走 CDN 缓存吗？

- 答：一般不建议直接缓存带用户敏感信息或强个性化的 API 响应。若确需缓存，可采用按接口分级缓存：对可以短时缓存的数据（如排行榜）在回源设置短 TTL，或在 CDN 配置按照路径/参数缓存，并严格排除带 Authorization/Cookie 的请求。

问：如何把缓存清除纳入自动化 deploy 流程，避免手工操作？

- 答：在 CI/CD 的部署脚本中加入：1) 构建并生成带 hash 的资源与 manifest；2) 上传资源到回源或对象存储；3) 使用加速乐的 API Key 调用缓存清除接口，提交要清除的 URLs 或路径模式；4) 可选地触发预热脚本并验证关键资源的返回头。将这些步骤作为部署流水线的一部分可以保证发布一致性与可追溯性。