API 服务上 CDN：动态接口不缓存、静态资源单独缓存

做 API 服务的 CDN 接入时，最容易踩的坑不是配不通，而是缓存配错了：动态接口被缓存、静态资源没缓存、长连接被掐断。下面是我总结的四条实战原则。

一、动态接口：全程不缓存

CDN 默认只缓存 GET/HEAD，POST 默认不缓存，这能挡住一部分问题，但挡不住全部。很多动态接口本身就是 GET：模型列表、用户信息、余额配额、任务状态——这些 URL 一旦被边缘节点按地址缓存，下一个用户就可能拿到上一个用户的响应。

做法是双保险：源站对动态接口返回 Cache-Control: no-store；CDN 侧再配一条覆盖全部 API 路径的规则，边缘和浏览器都不缓存。配完要验证：连续请求同一接口，看响应头里的缓存状态是不是每次都是 MISS，而不是第一次 MISS、之后变 HIT。

二、静态资源：单独建一条缓存规则

js、css、字体、图片这类静态文件，和动态接口走同一套规则就是浪费。单独按文件后缀建规则，边缘节点缓存 7 天左右；配合构建时给文件名加哈希，更新即换名，旧缓存自然失效。

但有一个例外：入口文件（比如 index.html）不要长缓存。它本身不带哈希，一旦被缓存，新版本就推不出去。入口文件走不缓存或很短的缓存，静态资源走长缓存，这才是正确的分层。

三、长连接：超时和压缩要单独处理

SSE 流式输出、WebSocket 这类长连接，最怕两件事：一是 CDN 回源超时太短，流还没推完就被掐断；二是压缩把流式输出缓冲住了，内容攒一批才吐一次，看起来像卡顿。

所以回源超时要按最长的一次会话来设（比如 600 秒），WebSocket 开关要确认打开；压缩（Gzip/Brotli）只对普通文本响应开，对 SSE 排除。改完之后要实测一次完整的流式会话，确认从第一个 token 到结束不断流。

四、HTTPS 与回源：先保证链路本身没问题

强制 HTTPS 跳转、HSTS、TLS 最低 1.2，这些是基线。回源协议看源站条件：如果源站有证书就用 HTTPS 回源；如果源站只接受带特定校验头的请求（比如自定义回源头），CDN 侧要配好注入，否则源站会直接 403，表现就是全站 5xx，很容易误判成 CDN 故障。

最后给一个上线检查清单：动态接口每次请求都是 MISS；静态资源第二次请求是 HIT；一次完整的 SSE 会话不断流；http 访问能 302 到 https。这四项都通过，CDN 这层才算真正接稳了。