要让html中的静态图片被浏览器长期缓存，需设置cache-control: public, max-age=31536000, immutable，并配合文件名哈希（如logo.a8f3b2e7.png）实现更新即生效，辅以etag/last-modified协商缓存及cdn缓存头一致性校验。
要让HTML中的静态图片资源被浏览器长期缓存，关键不是“不让它缓存”，而是“让它安心缓存，又能在更新时自动失效”。核心在于服务端正确设置HTTP缓存头，配合前端资源标识策略，实现「一次加载、长期复用、更新即生效」。
给图片响应头配好Cache-Control
这是最直接有效的控制方式。服务器返回图片时，必须在HTTP响应头中设置明确的缓存指令：
- 静态图片（如logo.png、banner.jpg）应设为public + 长期max-age + immutable： Cache-Control: public, max-age=31536000, immutable 表示该资源可被所有中间节点和浏览器缓存1年，且内容不会变更（浏览器无需再发条件请求验证）。
- 避免只用Expires：它依赖服务器时间，易因时间偏差导致缓存异常；Cache-Control优先级更高、语义更清晰。
- 不要对所有图片统一设no-cache或max-age=0——这等于放弃缓存收益，白白增加请求量和带宽消耗。
用文件内容哈希替代时间戳做版本标识
仅靠后缀加?t=时间戳虽能强制刷新，但会完全破坏缓存复用性。更优解是把“更新信号”融入文件名本身：
- 构建时对图片生成内容哈希，例如logo.a8f3b2e7.png，内容变则文件名变。
- HTML中引用该带哈希的文件名：
<img src="logo.a8f3b2e7.png">。 - 这样浏览器始终认为它是全新资源，首次加载后即可长期缓存；下次更新时，新哈希文件名自然触发新缓存，旧文件可由CDN或服务端定期清理。
搭配ETag或Last-Modified做协商缓存兜底
即使设置了强缓存，也建议服务器同时提供ETag或Last-Modified头：
- 当用户手动刷新（F5）或网络异常导致强缓存失效时，浏览器会发起带If-None-Match或If-Modified-Since的条件请求。
- 服务器比对后若资源未变，返回304 Not Modified，不传图片体，节省带宽。
- 这对开发阶段调试或低频访问图片尤其有用，属于低成本高回报的补充机制。
注意CDN与代理缓存的一致性
如果网站使用CDN或反向代理（如Nginx），需确保它们同样尊重并透传Cache-Control头：
- 检查CDN后台是否开启“遵循源站缓存头”选项，避免CDN自行覆盖为短缓存。
- Nginx中确认未全局配置expires指令误覆盖图片响应头。
- 可借助浏览器开发者工具的Network面板，查看图片响应头是否真实包含你设定的Cache-Control值，并确认Status显示为200 (from memory cache)或304。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
