CDN 缓存优化，先证明同一个缓存键对应同一份内容

先按响应语义选择缓存方式

适用边界：CDN 只减少适合复用的传输与计算

CDN 适合静态资源、公开内容和经过明确设计的可缓存响应。数据库锁、写入热点、慢查询、外部接口或用户态业务逻辑不会因前面增加 CDN 自动消失；命中请求减少源站工作，未命中和不可缓存请求仍需真实容量。

先从访问日志和链路指标区分静态资源、HTML、公开 API、私有 API、上传和流式连接，记录每类请求量、对象大小、响应时间、状态码、来源地区与当前 Cache-Control。只看全站命中率会掩盖关键接口完全回源，也会把小图标的高命中误当作数据库压力已经下降。

小程序和 APP 可能同时经过客户端缓存、系统网络栈、CDN、网关和应用缓存。每一层的键、有效期和刷新能力都要画在同一链路上，避免团队只刷新 CDN，却忽略客户端仍持有旧配置。AI 智能体调用的业务接口也不能因为读取频繁就默认共享缓存；先确认用户委托、租户、权限和数据时效。

• 列出各路由是否公开、可否复用、允许陈旧时间和权威来源。
• 保留接入前的源站请求、带宽、状态码、延迟与资源基线。
• 明确本次不缓存的身份、交易、写请求、流式与结果未知场景。

缓存键只包含会改变响应且基数可控的输入

缓存键太窄会把不同响应错误合并，太宽则会把同一公开内容切成大量小份并持续回源。路径之外，需要逐项判断查询参数、请求头、Cookie、语言、压缩格式与设备差异是否真的改变表示形式。

RFC 9111 说明缓存键至少基于请求方法和目标 URI，并通过 Vary 指定会影响选择已存响应的请求头。工程上不能简单地把所有请求头、Cookie 和查询参数都加入键：追踪参数、随机数、完整 User-Agent 或会话 Cookie 往往基数很高，会降低命中并增加存储和回源；反过来忽略语言、格式或有效业务参数，又可能返回不匹配内容。

建立路由级缓存契约：列出规范化 URL、参数白名单、空值与默认值、大小写、排序、尾斜杠和重写前后的地址。重定向、404 与部分响应也可能被缓存，应为错误和不存在资源单独定义较短、可观察的策略，避免一次临时故障被长时间放大。缓存供应商的键和源站收到的请求字段可能由不同策略控制，上线前需按实际产品验证。

• 对每个键字段写明为什么改变响应，并估算可能的取值基数。
• 用等价请求验证可以命中，用不同语言、格式、租户和权限验证不会串用。
• 统一 URL 重写、大小写、参数排序与尾斜杠规则，减少隐藏变体。

用响应语义控制存储、复用、验证与陈旧

Cache-Control 不是一组可以全站复制的固定模板。需要区分浏览器私有缓存与共享缓存，明确响应能否存储、何时变陈旧、陈旧后必须验证还是允许在限定条件下继续服务，并为紧急撤回保留路径。

公开不可变资源以内容哈希或版本目录改变 URL，文件内容与地址形成稳定关系；入口 HTML 或配置使用较短有效期、条件验证或受控刷新。RFC 9111 对 no-store、private、no-cache、max-age、s-maxage 和 must-revalidate 分别定义不同语义，其中 no-cache 不是“绝不存储”，而是复用前必须成功验证。具体 CDN 还可能用自身最小或最大 TTL 覆盖源站意图，例如 CloudFront 官方文档明确提示，最小 TTL 大于零时可能至少缓存该时长，即使源站返回 no-cache、no-store 或 private。

账号页面和带 Set-Cookie 的响应不能只凭“通常不缓存”来放心，应在 CDN 行为和实际响应上显式验证。若业务选择在源站异常时服务陈旧公开内容，要标明数据时间与适用范围；权限、余额、库存确认和写操作结果不能用旧值伪装成功。配置变更由代码或版本化策略管理，不依赖控制台中无法追踪的临时点击。

• 逐类记录 Cache-Control、CDN TTL 上下限、错误缓存与验证方式。
• 对敏感响应检查 private 或 no-store 等预期指令及共享节点实际行为。
• 把源站故障时可服务旧值和必须失败的业务分别列入降级矩阵。

失效与冷启动必须受源站容量约束

刷新缓存会让下一次请求重新访问源站。若大量热门对象在同一时间过期、全站刷新或新节点同时预热，回源峰值可能高于平时；缓存优化不能以“正常命中时源站很小”为由忽略冷缓存容量。

先识别热点对象、对象数量和过期分布，避免所有内容使用同一个固定到期时刻。能用版本化 URL 发布的资源不必全局刷新；必须原 URL 生效的 HTML、配置或紧急下架内容，采用精确路径和可审计批次，并观察刷新进度与源站负载。CloudFront 官方资料把失效与版本化文件名列为不同更新方式，并建议频繁更新内容优先使用版本化名称，因为它更便于控制缓存、日志分析和前后版本切换；这一思路仍需结合所用 CDN 的实际能力。

源站设置独立的认证、防绕过、连接和并发预算，不能让攻击者或错误客户端直接绕开 CDN 打满源站。对同一个热点键的并发未命中，可使用平台支持的请求合并、分层缓存或受控预热降低重复回源，但不要假设所有节点或不同缓存键会自动合并。刷新、预热和爬虫流量也纳入限速，优先保护登录、下单和必要 API。

• 发布前测量冷缓存、热点过期、全站回源与源站故障场景。
• 资源过期时间分散，刷新按路径和批次执行并能随时停止。
• 源站有独立的访问边界、容量告警和绕过 CDN 的应急控制。

实施步骤：先做不可变静态资源，再扩大到公开动态内容

第一阶段为构建产物增加内容哈希并保留旧资源，核对 HTML 与资源版本；第二阶段为图片、下载和公开文件设定缓存；第三阶段才选择一条允许短暂陈旧的公开 API，明确键、TTL、验证、错误和失效；每一阶段都保留按路由关闭缓存的开关。

发布流程先上传新资源，再发布引用它们的入口，回滚时让入口重新引用仍然存在的旧资源。不要在切换后立刻删除旧哈希文件，已打开页面、浏览器缓存和边缘节点可能仍会请求它们。对 HTML 与 API 使用合成请求检查 Age、Cache-Control、Vary、ETag 或 Last-Modified 等实际响应，以及供应商命中状态；这些字段和状态的含义按使用平台确认，不能只看控制台配置截图。

继续比较命中和未命中的端到端延迟、源站请求、带宽、错误、缓存变体数量与费用。命中率下降时先按路由、参数和状态码拆解，确认是否因为发布、热点变化、查询参数污染、Cookie 或配置漂移。压测请求要包含真实参数分布和冷启动，不能重复访问一个 URL 后用接近满命中的结果代表全站容量。

• 每次只新增一类可缓存响应，并准备路由级停用与回滚配置。
• 发布顺序为新资源先到位、入口后切换、旧资源在兼容窗口后再清理。
• 用真实参数和身份矩阵检查缓存键、响应头、命中状态与源站指标。

验收与风险：命中率、正确性和回源恢复一起通过

验收覆盖匿名与登录、不同租户、语言和格式、查询参数排列、冷缓存、热点失效、刷新、源站慢或不可用、版本发布与回滚。先证明内容和权限正确，再评价源站减载与用户延迟；任何跨身份串用都应停止发布。

功能验收核对静态资源校验值、HTML 引用、公开 API 数据截止时间、错误响应有效期和紧急撤回。性能验收分别记录边缘命中、重新验证、未命中和绕过请求，不用供应商总请求数代替源站真实接收量。恢复验收证明源站恢复后缓存逐步重新填充，不会被客户端重试、批量刷新和预热同时冲垮。

主要风险包括缓存键遗漏造成越权或错内容、键基数过高导致命中下降、TTL 与业务时效不符、错误页或空结果被长期缓存、发布中删除旧资源、刷新制造回源洪峰，以及配置只存在控制台无法复核。最终交付保留路由契约、响应头样例、策略版本、刷新记录、源站容量证据和未缓存清单；不能承诺 CDN 一定提高搜索排名，也不能把边缘命中等同于业务接口已经正确。

• 证明不同身份、租户、语言、格式和参数组合不会错误复用。
• 证明发布、回滚、紧急刷新、冷缓存和源站故障均有受控行为。
• 报告同时包含命中分布、源站减载、延迟、错误、费用与未覆盖边界。

需求讨论中的问题

关联服务与实施资料

下面的页面可继续核对相关技术边界、业务接入方式与项目交付条件。

• 缓存穿透、击穿与雪崩指南：继续处理应用缓存回源、热点键和批量过期，不把 CDN 当作唯一缓存层。
• 容量规划指南：把冷缓存、刷新和未命中流量纳入源站 QPS、带宽与故障余量。
• API 重试风暴治理指南：限制边缘失败、客户端补发与源站恢复时的请求放大。
• AI Agent 智能体开发：为智能体查询区分公开知识、用户委托、租户权限与数据时效。
• 小程序与 APP 一体化开发：统一多端资源版本、接口授权、客户端缓存和灰度发布边界。
• 软件项目启动资料包：整理路由、流量、版本、源站容量与发布验收责任。