HTTP 缓存与 CDN 加速实践：先划定 API 响应的可缓存边界
缺少接口契约与 CDN 配置材料时，缓存与加速应先判断响应是否可共享、缓存键是否稳定、失效是否可控；具体 TTL、命中率和 API.PLUS 的支持范围待核实。
HTTP 缓存与 CDN 能否加速 API，不取决于“是否开了 CDN”，而取决于三件事：响应是否允许共享缓存、缓存键是否稳定、失效是否可控。本文不假设 API.PLUS 已提供某种缓存能力，也不给出具体 TTL 或命中率；这些需要结合接口契约、CDN 厂商配置与业务一致性要求核实。
先判断：这份响应能不能进入共享缓存#
CDN 通常位于客户端与源站之间，属于共享缓存的一环。按 HTTP 缓存语义，Cache-Control: private 的响应不应被共享缓存存储，no-store 则要求不存储。涉及用户身份、权限、一次性令牌或写操作结果的响应，默认应按不可共享处理，除非接口契约明确说明可缓存范围。
| 响应特征 | 共享缓存判断 | 工程建议 |
|---|---|---|
| 公开目录、静态元数据 | 可考虑 | 先确认数据更新频率，再设计缓存键与验证方式 |
| 含用户身份或权限差异 | 默认不建议 | 使用 private 或 no-store，避免中间层复用 |
| 一次性令牌、支付结果 | 不建议 | 不要用缓存掩盖重复请求问题 |
| 高频变化的列表 | 需谨慎 | TTL 与验证策略待业务确认，不宜照搬静态资源 |
缓存键：先定义“同一份响应”#
缓存键决定哪些请求可以复用同一份响应。常见组成包括主机、路径、查询参数，以及 Vary 声明的请求头。风险在于：为了提升命中率而忽略全部查询参数，可能把不同筛选条件的结果混在一起；反过来，把无意义的参数全部纳入键，又会降低复用率。
- 查询参数应按接口语义建立白名单，并固定排序规则。
- 需要按语言、编码或客户端能力区分时，用
Vary明确声明，避免隐式差异。 - 带
Authorization的请求是否可共享，必须以接口契约为准，不能仅凭路径相同判断。
条件请求与失效顺序#
对于可缓存但需要验证的响应，可使用 ETag 或 Last-Modified，客户端再以 If-None-Match 或 If-Modified-Since 发起条件请求。源站返回 304 时，客户端可复用已有表示；但这要求源站正确生成验证器，且中间缓存没有错误改写响应头。
失效顺序建议是：先确认源站已发布新响应，再按精确缓存键清理 CDN，最后观察回源与命中情况。不要先全网清空再排查源站错误；否则缓存被清掉后，错误响应可能直接暴露给用户。CDN 的清理粒度、传播时间和 API 支持范围待核实。
最小排查顺序#
- 查看响应头中的
Cache-Control、ETag、Vary，确认是否与接口契约一致。 - 用不同查询参数和请求头发起请求，确认缓存键没有把不同响应合并。
- 检查条件请求是否返回
304，以及验证器是否随内容变化。 - 发布新版本后，先验证源站，再执行精确失效，最后观察回源量。
下面仅是占位示例，未实际执行，也不能作为 API.PLUS 端点或响应结果：
curl -I "https://api.example.com/v1/items?limit=20"如果响应中出现 Cache-Control: public, max-age=60，那只是语法示意，不构成 TTL 建议。实际 TTL 应依据数据一致性要求、访问规模和 CDN 计费/清理能力确定；这些信息本次材料未提供，需另行核实。
边界说明：本文只给出可缓存性判断、缓存键设计和失效顺序的通用方法，不声称 API.PLUS 具备特定缓存功能，也不提供未经验证的性能数字。
