API缓存：控制新鲜度、隔离与一致性

发布 03/05/2026 · 更新 23/10/2026 · API与系统集成 · 5 分钟阅读 · 作者 Cyber Intelligence Embassy

内容摘要

缓存通过复用响应减少部分计算或传输。价值取决于键、权限、可接受时效，以及源站不可用时的行为。

本文目录

区分应用缓存和HTTP缓存

Redis、Workers KV与HTTP缓存并不自动拥有同样保证。Workers KV使用最终一致性，写入不会立即在各处可见。以下指令面向HTTP缓存，不能单独配置应用缓存。

HTTP响应指令	主要含义	限制
no-cache	允许存储，但复用前需验证。	不表示禁止存储。
no-store	不要在缓存中存储此响应。	不会自动删除旧副本。
private	不存入共享缓存。	不是身份认证规则。
max-age	响应的新鲜有效期。	不保证所有数据一致。

测试正确的人收到正确响应

按资源、参数、语言和权限范围定义缓存键差异。测试一个账户绝不会收到另一个账户的私密响应。
规定最大时长、失效机制以及修改或删除后的行为。短TTL不保证立即一致的读取。
测试同时过期、缓存故障与源站故障。必要时合并刷新，只有业务规则允许时才返回过期响应。

测量命中率之外的结果

跟踪延迟、错误、源站负载以及错误或过时响应。余额、预留库存和权限可能需要不同于公开目录的保证。快速缓存不能成为失控的替代事实来源。

一手资料

API 缓存必须保留访问决策。

当键忽略请求者权限时，响应缓存可能会快速执行错误的查询。当图包含公共对象和私有对象时，风险会增加。

缓存前对公共字段、私有字段和角色相关字段进行分类。
在一个帐户下测试响应，并在另一个帐户下请求该响应。
权限或数据更改后使结果失效。

一手资料：OWASP — GraphQL Cheat Sheet. 相关方法：阅读实用指南.

同时衡量缓存速度与新鲜度

虚构示例：数据不代表客户或实际观察结果。

两次读取都很快，但数据源变化后，其中一次仍显示旧的可用状态。

比较数值、版本、读取位置和变更后的时间，按系统约定测试失效、过期以及访问原始来源。
按用途明确可接受的过时程度并监测差异。延迟降低不能证明已提供数据的一致性。

一手资料：IETF — RFC 9111, HTTP Caching. 相关方法：阅读实用指南.

废弃子域名：受控移除CNAME指向

将DNS名称对应到受控资源，在释放服务前关闭依赖。

记录公开名称、CNAME链、供应商资源和负责人，对照授权账户清单与DNS。HTTP错误、NXDOMAIN或资源缺失需要调查，不能证明可被接管；供应商保护不同。
先删除指向或改为受控目标，再释放资源。考虑原有TTL和缓存，检查权威DNS及多个解析器。保留仍需使用的所有权验证，不要统一删除TXT记录。
检查链接、重定向、OAuth回调、webhook及Cookie域。若资源已释放，修正DNS并按事件流程调查可能暴露。每次删除后核对DNS与资源清单。

可复现的验收案例

虚构示例：数据不代表客户或实际观察结果。

查看案例输入

{
    "name": "portal.example",
    "cname_present": true,
    "resource_deleted": true,
    "provider_claimability": "not_verified",
    "takeover_observed": false,
    "expected": "remove_or_replace_mapping_and_review_exposure"
}