CDN 现在解决哪些问题
传统 CDN 把可缓存文件放到离用户更近的节点，减少重复回源；现代产品还可能提供边缘函数、图片转换、流量过滤、负载均衡等组件。但这些能力属于不同产品层级，不能用一个“CDN”概念覆盖全部。请求链路可以概括为：用户 DNS/连接 → 边缘节点 → 按缓存键查找 → 必要时回源 → 返回响应。
缓存正确性比缓存率重要
缓存键由 URL、查询参数、请求头等参与决定，不当配置会把不同用户的内容混为一份。对 HTML 与 API，要显式确定是否公开缓存；用户会话和支付结果应设置 private 或 no-store，同时测试边缘规则是否覆盖源站头部。源站更新后，还要考虑 TTL、资源版本号和清理缓存的延迟。
动态加速与边缘计算的边界
动态请求无法像静态图片一样总是直接命中边缘，所谓加速可能来自连接复用、路由优化、协议配置或将部分逻辑下沉。边缘计算能减少部分网络往返，却引入执行限制、数据一致性和调试成本。不要根据宣传图声称所有业务都能获得统一倍数提升。
选择路线
先画出业务请求图，再按静态比例、用户地区、源站出口费、规则管理能力和可观察性选服务。对于多 CDN 架构，还需要配置健康检查、证书同步和故障转移，而不只是两家厂商 DNS 轮询。
CDN 演进这篇抓住了缓存键和私密响应两个核心风险。尤其是登录态、支付结果、带 Cookie 的 HTML，不能为了命中率强行缓存；应明确 Cache-Control、Vary、失效策略和回源鉴权，缓存正确性比命中率更重要。