动静混合站点怎么加速
全站加速在静态缓存的基础上，为动态请求提供智能选路与协议优化回源，适合既有静态资源又有动态接口的站点。配置重点有两个：动静分类要准确，静态资源留在边缘、动态接口保持回源；回源要跟随站点实际拓扑，避免动态请求被误当作静态内容缓存。各厂商命名不同，能力细节以自家文档为准。
基本信息
| 适用场景 | 既有静态资源又有动态接口的站点 |
|---|---|
| 静态部分 | 按缓存规则留在边缘，可按需配置较长 TTL |
| 动态部分 | 智能选路回源，不缓存或按业务需要严格控制 |
| 产品命名 | 不同厂商命名不同，能力细节以各自文档为准 |
| 核实方式 | 用真实动态接口验证未被缓存 |
典型使用场景
- 官网与企业站：页面静态、表单与接口动态
- 小程序与 App 的后端接口加速，改善跨地域访问质量
- 跨境访问动态接口时延迟高，评估智能选路收益
- 迁移传统 CDN 到全站加速，先核对动静分类是否正确
- 排查「接口返回被缓存」：确认动态路径是否被当作静态处理
分别验证动态与静态
分别验证动态与静态
# 动态接口：期望不被缓存
test=$RANDOM
curl -sI "https://cdn.example.com/api/user?id=$test" | grep -i -E 'x-cache|age|cache-control'
# 静态资源：期望命中边缘缓存并带 age
curl -sI https://cdn.example.com/assets/logo.png | grep -i -E 'x-cache|age|cache-control'动静分类参考
| 内容类型 | 建议处理 | 原因 |
|---|---|---|
| 图片与静态资源 | 边缘缓存，长 TTL | 内容稳定，回源成本高 |
| HTML 入口页 | 短 TTL | 需要及时指向新资源 |
| REST 接口 | 不缓存或按参数区分 | 返回内容与用户或入参相关 |
| 上传与回调 | 不缓存 | 请求具有副作用 |
不同厂商对全站加速的命名与边界不同，迁移或对比产品时以各自文档中的能力说明为准，不要按名称想当然。
动静分类错误时动态请求会走缓存链路，表现为用户看到旧数据或他人数据，属于影响面较大的配置错误。