EdgeOne 缓存、更新与动态 API 边界

01先按资源类型设置缓存

带内容哈希的 JS/CSS 可以使用长缓存；入口 HTML 应能及时重新验证。否则页面可能长期引用旧资源，让内容更新看起来没有生效。

使用 EdgeOne 的配置文件或控制台设置响应头前，核对当前文档支持的字段与作用范围。避免在多个层面为同一路径写互相冲突的规则。

02每次发布验证新旧版本切换

先验证新访客能拿到当前构建，再检查已有缓存的浏览器是否能平稳更新。确认 HTML 引用的资源仍可访问，且不会因为缓存清理顺序短暂出现空白页面。

• 检查 HTML、CSS 和 JS 的 Cache-Control。
• 检查 CDN 命中、状态码和内容类型。
• 发布后直接打开文章链接并刷新。
• 故障回退后再次验证资源版本一致性。

03未来接入 API 时单独设计

需要用户身份或模型请求的接口与静态内容采用不同策略。服务端保存密钥，按用户和项目鉴权，动态请求不套用静态公共缓存规则。

流式响应还要检查函数运行时、连接时长、响应缓冲、错误转发和取消传播。平台限额可能变化，应以当前官方限制页与实际测试为准。

04响应头配合站点实际能力

为 HTTPS、嵌入、来源和脚本加载制定明确规则。安全策略过松会扩大攻击面，过紧也可能阻断合法资源；先在预览环境测试后再应用生产。

05用响应头核对实际缓存策略

配置文件描述的是意图，线上响应头才是浏览器与 CDN 实际拿到的结果。发布后选取 HTML 和一个真实哈希资源分别检查。

下方地址是占位示例；将它替换为预览或生产地址。除了 Cache-Control，还要确认状态码、Content-Type 与安全响应头。

curl -I https://wiki.example.com/
curl -I https://wiki.example.com/index.html
# 将文件名替换成此次构建的真实资源
curl -I https://wiki.example.com/assets/index-HASH.js