强缓存通过cache-control的max-age指令控制，即浏览器在指定秒数内直接读取本地缓存、不发起网络请求；max-age单位为秒，优先级高于expires，设为0则立即过期触发协商缓存。
强缓存通过 Cache-Control 的 max-age 指令控制，核心是让浏览器在指定秒数内直接读取本地缓存，不发起任何网络请求。
max-age 的基本写法和含义
max-age 表示资源在客户端缓存中的有效时间（单位：秒），由浏览器自行计算过期时间，不受系统时钟影响。它优先级高于 Expires，两者同时存在时以 max-age 为准。
-
Cache-Control: max-age=3600→ 缓存 1 小时，期间所有请求都命中本地缓存（状态码 200 from memory/disk cache） -
Cache-Control: max-age=0→ 立即过期，每次都会触发协商缓存或重新请求 -
Cache-Control: no-cache不等于禁用缓存，而是跳过强缓存，强制走协商缓存（如 ETag 或 Last-Modified）
静态资源推荐配置（JS/CSS/图片）
这类文件通常内容稳定、通过构建哈希命名（如 app.a1b2c3.js），适合长期强缓存。
Cache-Control: public, max-age=31536000, immutable-
public允许 CDN 和浏览器共同缓存 -
max-age=31536000对应 1 年，避免频繁验证开销 -
immutable告诉浏览器：只要 URL 不变，内容绝不会变，连 Ctrl+F5 强刷也不发请求
HTML 入口页的特殊处理
HTML 文件必须保证更新及时可见，不能依赖长期强缓存。
-
Cache-Control: no-cache→ 每次都向服务端验证（需配合 ETag 或 Last-Modified 才有意义） - 或
Cache-Control: max-age=60→ 最多缓存 1 分钟，兼顾性能与更新敏感性 - 避免设
max-age=86400或更长，否则用户可能加载旧版 HTML，导致新 JS 路由或功能不可见
常见错误避坑点
配置 max-age 时容易忽略协同机制，导致缓存失效或更新延迟。
- 只设
no-cache却没返回ETag→ 每次都全量回源，失去协商缓存价值 - 用查询参数做版本控制（如
main.js?v=2.1.0）→ 多数 CDN 默认忽略 query string，无法正确缓存 - 给路由 JS 文件设了
max-age=31536000但没加哈希 → 文件名不变，内容更新后用户无法获取新版
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
