cache-control: max-age=2592000是静态资源强缓存最稳妥起点，需配合文件名哈希或版本号；因浏览器优先认cache-control，max-age为相对时间更可靠，expires仅兼容极老客户端。
直接结论：用 Cache-Control: max-age=2592000（30天）是静态资源强缓存最稳妥的起点，但必须配合文件名哈希或版本号，否则改了文件用户看不到更新。
为什么只设 max-age 就够了，不用 Expires
浏览器优先认 Cache-Control，Expires 仅用于兼容极老客户端（如 IE8 及更早）。max-age 是相对时间（从响应发出那一刻算起），不依赖服务器和浏览器时钟同步；而 Expires 是绝对时间戳，一旦客户端时间被手动调快/调慢，缓存就可能提前失效或长期不更新。2026 年已无必要双写。
max-age 值设多大才合理
常见误区是“越大越好”，实际要平衡更新可控性与缓存收益：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
max-age=31536000（1年）适合带内容哈希的资源（如main.a1b2c3.js），改内容必改文件名，缓存可彻底放飞 -
max-age=2592000（30天）是通用安全线，覆盖多数 CDN 和浏览器默认行为，也留出人工干预窗口 -
max-age=604800（7天）适合未做哈希但有构建流程注入版本参数的项目（如style.css?v=2.3.1） - 别设
max-age=0或负数——那不是“不缓存”，而是触发协商缓存（发If-None-Match请求），反而增加请求数
Apache 中配置 max-age 的典型陷阱
在 .htaccess 或 httpd.conf 里用 Header set Cache-Control 时，容易忽略三点：
- 必须启用
mod_headers模块，否则配置静默失效 -
FilesMatch的正则要精确，比如写成\.(js|css|png|jpg|woff2)$，别漏掉woff2或误配html（HTML 不该强缓存） - 不要叠加写多个
Header set，后写的会覆盖前写的；想加immutable就得合并：Header set Cache-Control "max-age=31536000, immutable" - 确认虚拟主机配置没在别处用
Header unset Cache-Control把你刚设的干掉了
验证缓存是否生效的关键检查点
光看响应头不够，得看真实行为：
- Chrome DevTools → Network 标签页 → 刷新资源，看 Status 是
200 OK (from memory cache)还是200 OK (from disk cache)，才是强缓存命中 - 如果显示
304 Not Modified，说明走的是协商缓存（ETag或Last-Modified），max-age没起作用 - 用
curl -I https://yoursite.com/app.js看返回头是否真含Cache-Control: max-age=2592000，注意大小写和空格（中间不能有多余空格） - 修改资源后清掉本地缓存再测——浏览器有时会“记住”旧的
max-age值，哪怕服务器已改配置
真正难的不是设数字，而是确保每次资源内容变化时，URL 必须变化；否则哪怕 max-age 设成 1 秒，用户也可能卡在旧版本里不动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
