动态内容加速：登录页面和业务 API 的缓存边界
动态业务的优化不只是提高缓存命中率。先区分公开内容与用户数据，再评估回源、连接复用及真实请求时延，避免加速规则破坏账号隔离。
本文目录
不是每个响应都适合共享
公开文章、版本化脚本和图片通常可以设计共享缓存；订单详情、账号资料和带权限的导出结果则要单独处理。同一个 URL 返回什么内容，可能取决于 Cookie、Authorization、语言或查询参数。仅凭 .html 或 .json 后缀决定缓存策略，容易把业务差异隐藏起来。
三个响应头概念要分清
HTTP 缓存规范中的 private 限制共享缓存存储响应；no-store 要求缓存不要存储；no-cache 则允许存储，但再次使用前需要成功验证。它们不是同一个含义。Vary 用于声明影响响应选择的请求头，也不能替代业务鉴权或所有查询参数的缓存键配置。
不缓存，仍然可以优化交付
对于必须回源的请求，建议拆开观察 DNS、连接建立、TLS、源站计算和响应传输的耗时。连接复用、合理超时和回源链路选择可能改善交付效率，但最终收益需要从实际用户区域测量。如果主要等待发生在数据库或第三方接口，应先处理应用依赖。
用两套账号验证隔离
为公开资源、登录接口和敏感页面各选一个样本。先用账号 A 访问，再由账号 B 和未登录客户端访问相同地址，核对响应内容、状态码与缓存行为。随后修改源站内容，确认刷新和失效策略符合预期。不要用真实客户的敏感数据做这类测试。
选型看业务体验，不只看命中率
对登录门户、SaaS 和 API 服务，建议将成功率、较慢请求的时延、错误重试和回源负载放在同一张验收清单里。固定业务带宽决定传输能力，正常流量不计量描述计费方式；二者都不能直接推导出无限并发或任意请求都能缓存。