关键一步是配置Cache-Control响应头：静态资源用public, immutable, max-age=31536000实现长期强缓存；HTML用no-cache, must-revalidate或private, max-age=600；API按实时性分级设置，同时需配合文件哈希与压缩。
加载速度提升的关键一步，是让浏览器和 CDN 尽可能复用已下载的资源，而不是反复请求服务器。而 Cache-Control 就是控制这一步最直接、最有效的响应头。
静态资源（JS/CSS/图片）配长期强缓存
这类文件内容稳定、更新靠文件名变化（如 main.a1b2c3.js），适合设置最长有效期：
- 加
public：允许 CDN、代理、浏览器共同缓存 - 加
max-age=31536000（1 年）：避免频繁校验 - 加
immutable：告诉浏览器“这个文件名下的内容永远不会变”，跳过后续的If-None-Match验证请求
示例响应头：
Cache-Control: public, immutable, max-age=31536000
HTML 文件配短时或协商缓存
HTML 通常动态生成，不能简单设长缓存。但全禁用也不合理，推荐两种方式：
- 设
no-cache, must-revalidate：允许缓存 HTML，但每次使用前必须向服务器验证（用 ETag 或 Last-Modified） - 或设
private, max-age=600（10 分钟）：仅浏览器缓存，适合用户登录态页面等轻度动态内容
注意：如果 HTML 内联了 JS/CSS 或引用未带哈希的资源，再长的缓存也没用——用户仍会加载旧逻辑。
API 接口按业务需求分级配置
不是所有接口都该禁缓存，也不是都能缓存。关键看数据实时性要求：
- 用户资料类（变动少）：可设
private, max-age=300（5 分钟） - 订单状态、支付结果：建议
no-store，彻底禁止缓存，防止敏感信息泄露或状态错乱 - 列表页、搜索结果：可用
no-cache, max-age=0，缓存内容但强制每次验证
特别提醒：攻击者可能伪造 Cache-Control: no-cache 头发起回源洪泛。若 CDN 已启用节点缓存，且源站没返回 no-store，这类请求仍走本地缓存，不会打穿源站。
别忘了配合构建与压缩
光写对 Cache-Control 不够，还要确保底层支撑到位：
- JS/CSS 输出必须带内容哈希（如 Webpack 的
contenthash），否则改了文件内容却没改名，用户永远拿不到新版本 - 开启 Gzip 或 Brotli 压缩，HTML/JS/CSS 体积常减少 50%~70%，加载更快
- Nginx 中慎用
expires指令，它生成的Expires头优先级低于Cache-Control，容易造成预期外行为
