静态图片长期缓存需协同响应头、文件名哈希与协商缓存：设Cache-Control: public, max-age=31536000, immutable；用内容哈希命名（如banner.7a2f9c4e.jpg）确保更新即生效；辅以ETag/Last-Modified兜底验证。
静态图片资源要实现真正有效的长期缓存，核心不是“设个长过期时间”就完事，而是让浏览器和中间节点（如 CDN、代理）都明确知道：这个文件稳定、可共享、且更新时能自动失效。关键靠三件事协同：响应头精准控制 + 文件名自带版本标识 + 协商缓存兜底保障。
设置强缓存响应头：Cache-Control 是主力
服务端返回图片时，必须在 HTTP 响应头中写入明确、现代的缓存指令：
- 用 Cache-Control: public, max-age=31536000, immutable —— 表示该资源可被所有节点缓存 1 年，且内容不会变更，浏览器无需再发条件请求验证；
- 避免只依赖
Expires：它基于服务器时间，易因时间偏差出错；Cache-Control优先级更高、语义更可靠； - 不要对所有图片统一设
no-cache或max-age=0：这等于主动放弃缓存收益，徒增请求与带宽压力。
用内容哈希做文件名：更新即生效的关键
仅靠 URL 加 ?t=时间戳 会彻底破坏缓存复用性。正确做法是把“是否变更”的信号固化进文件名本身：
- 构建时根据图片内容生成哈希值，例如
banner.7a2f9c4e.jpg； - HTML 中直接引用该带哈希的路径：
<img src="banner.7a2f9c4e.jpg" alt="资源缓存策略怎么对静态图片资源设置长期缓存" >； - 这样每次内容变化，文件名就变，浏览器视其为全新资源，旧缓存自然淘汰，新资源可立即长期缓存。
补充协商缓存：ETag 或 Last-Modified 不可少
即使设置了强缓存，也建议服务端同时提供 ETag 或 Last-Modified 头：
- 当用户手动刷新或网络异常导致强缓存未命中时，浏览器会发带
If-None-Match或If-Modified-Since的条件请求； - 服务端比对后若内容未变，返回
304 Not Modified，不传图片体，节省带宽； - 这对开发调试、低频访问图片或 CDN 回源场景尤其有用，成本低、效果实。
检查 CDN 和反向代理的一致性
如果用了 CDN 或 Nginx 等反向代理，它们可能覆盖或忽略源站缓存头：
- 确认 CDN 后台已开启「遵循源站缓存头」选项，别让它擅自把图片缓存改成 30 分钟；
- Nginx 中检查是否误配了全局
expires指令，覆盖了你为图片单独设置的Cache-Control； - 用浏览器开发者工具的 Network 面板，真实查看图片响应头是否含你设定的
public, max-age=31536000, immutable，并确认状态显示为200 (from memory cache)或304。
