CDN接入前先盘点内容：按变化频率与用户差异划分缓存边界

🧭 CDN接入前先盘点哪些内容适合缓存

CDN缓存把响应保存在边缘节点，减少重复回源并缩短传输距离。它成立的前提是：同一个缓存对象在有效期内可以安全地服务多个请求。设计时应同时衡量内容变化频率、用户差异和可接受的陈旧时间，不能只看文件扩展名。

📦 先按内容性质分层

版本固定的静态资源

JS、CSS、字体和图片若文件名带内容摘要或发布版本，内容不变时可设置较长TTL。更新时生成新URL，旧对象自然退出引用链。若固定使用/app.js覆盖文件，长缓存可能让部分用户继续执行旧代码。

公共页面与个性化响应

公开文章页、公告页通常可考虑短TTL，但要明确更新延迟和刷新流程。账户、订单、购物车、管理后台及任何包含用户信息的响应，应默认避免共享缓存。路径看起来相同不代表内容相同：Cookie、授权状态、语言、设备或查询参数都可能改变响应。

🔍 用响应头和请求维度判定

采集代表性请求的Cache-Control、Vary、Set-Cookie、状态码和CDN命中状态。源站设置private或no-store时，应检查边缘规则是否尊重这些指令；不能因为某条规则配置了缓存，就假定它安全。Vary: Accept-Language表达了响应对语言的依赖，缓存层必须正确区分该维度，或改用明确的语言路径。避免把所有查询字符串一概忽略：utm类追踪参数可能不改变正文，而分页、尺寸、筛选参数常常会改变结果。

🛠️ 实施顺序与验收条件

1. 列出匿名页面、登录页面、API和静态文件各一组真实URL样例。
2. 为每组注明用户差异维度、目标TTL、刷新方式和责任人。
3. 动态内容从不缓存或极短TTL开始；验证一致性后再扩大公共页面范围。
4. 对静态资源确认文件名版本化，再使用长TTL；发布时检查新旧URL。

验收时用两个匿名会话和一个登录会话请求代表页面，确认个人字段不会互相出现；对语言、查询参数等变化分别请求，确认结果未被合并。连续请求同一公共对象，观察命中状态与年龄，并确认第二次请求符合预期。命中率提高不是安全验收指标：必须同时证明缓存对象边界正确、更新路径可用、个性化响应未共享。🎯