海外网站源站与边缘缓存协同部署，关键不是把所有内容都缓存起来，而是明确哪些内容可复用、缓存多久，以及内容更新后如何让旧副本退出。规则过松，动态页面可能泄露或显示过期信息；规则过严，边缘节点频繁回源，源站负载和跨境链路延迟都会上升。
可以把源站理解为内容的权威版本，把边缘缓存理解为靠近访问者的副本。比如源站位于法兰克福、用户分布在东京和悉尼时，静态文件适合由边缘节点就近响应；账户余额、订单状态等个性化内容则通常应绕过共享缓存。
先划分内容，再决定缓存策略
海外网站源站与边缘缓存协同部署，应从 URL、响应头和用户身份三方面盘点页面，而不是只按文件后缀判断。图片虽然通常适合缓存，带有临时权限或用户专属信息的下载地址却需要单独处理。
| 内容类型 | 常见策略 | 主要权衡 |
|---|---|---|
| 带版本号的图片、CSS、JavaScript | 可从数天到数周设置边缘 TTL；文件内容变更时更换版本路径 | 命中率高，更新依赖发布新地址 |
| 公共文章或商品说明页 | 可从几十秒到数分钟起步，再按更新频率调整 | 减轻回源，同时接受短暂旧内容 |
| 登录页面、购物车、账户接口 | 通常设置 private 或 no-store，或明确绕过共享缓存 | 降低信息串用风险，但请求更多到达源站 |
这些时间范围只是配置起点，实际 TTL 要结合内容更新频率、源站容量和业务对陈旧数据的容忍度验证。使用 Varnish Cache 或 Nginx 作为缓存代理时，也应检查代理规则是否正确遵循源站的 Cache-Control；采用 Fastly 等边缘服务时，则要核对其缓存规则是否覆盖或改写了响应头。
控制回源：缓存键与请求路径要一致
缓存键决定哪些请求共用同一份副本。若页面会因语言、设备或查询参数改变，却没有将相应字段纳入缓存键，访客可能收到错误版本；反过来，把无关参数都纳入缓存键，会拆散缓存，增加回源。Cookie 和 Authorization 请求尤其需要谨慎，不能为了提高命中率而忽略身份差异。
可执行的部署步骤
- 列出路由：按静态资源、公共页面、登录后页面和 API 分组，记录各组是否含用户差异及可接受的过期时间。
- 设置响应头：在源站为可共享内容配置 Cache-Control；对个性化内容使用 private 或 no-store。确认缓存服务对这些头的实际处理方式。
- 收紧缓存键：只保留确实影响响应的查询参数、语言或设备维度；对认证请求默认绕过共享缓存，完成隔离验证后再考虑例外。
- 先小范围验证：通过响应头或缓存服务日志检查 HIT、MISS、绕过状态，并对比不同地区、登录状态及参数组合下的响应内容。
- 设置回源保护：启用请求合并、限速或源站健康检查等可用能力；明确回源失败时是否允许返回短暂陈旧内容，避免错误地把旧数据用于账户或交易页面。
失效风险要靠发布方式和清理流程管理
缓存失效不只是“点一次清除”。大范围清理可能令大量请求同时落到源站，形成回源峰值；只清除部分路径，则可能让新旧 HTML 与脚本混用。对于静态文件，优先使用内容哈希或版本号生成新 URL，让新页面引用新资源，旧副本自然逐步退出。对于必须保持固定 URL 的页面，可按路径定向清理，并确认清理范围涵盖相关边缘节点。
建议将发布顺序设为：先上传新资源，再部署引用它们的页面，最后清理确需立即更新的缓存。上线后抽查响应头、页面版本和源站请求量；若源站短时承压，应先限制清理范围或错峰发布，而不是盲目延长所有内容的 TTL。海外网站源站与边缘缓存协同部署，也应保留回滚路径：出现错误版本时恢复源站内容，并再次定向清理。
常见问题
源站更新后，边缘节点多久能拿到新内容？
取决于 TTL、重新验证规则和清理方式。版本化资源通常随新 URL 更新；固定 URL 则需等待过期或主动清理，传播时间由所用服务及配置决定。
缓存命中率越高越好吗？
不一定。命中率要与内容正确性、安全边界一起看。登录数据或个性化响应不应仅为提高命中率而进入公共缓存。
源站不可用时是否应返回旧缓存？
公共且允许短暂过期的页面可评估 stale-if-error 一类策略；账户、库存或交易信息通常应避免返回可能造成误导的旧数据。
海外网站源站与边缘缓存协同部署应先优化哪一项？
先确认缓存键、认证请求绕过规则和内容分类，再调整 TTL。基础规则正确后，才适合依据日志逐步降低回源压力。
