浏览器是否缓存图片由服务器响应头Cache-Control决定，no-store彻底禁止缓存，no-cache强制每次验证；HTML meta标签无效，需后端为图片资源单独设置，或前端用动态时间戳URL绕过缓存。

用 Cache-Control 响应头强制不缓存图片

浏览器是否缓存图片，根本上由服务器返回的 HTTP 响应头决定，不是 HTML 标签能控制的。Cache-Control: no-cache 或 Cache-Control: no-store 是最直接有效的手段。前者允许浏览器在每次请求时向服务器验证（带 If-None-Match 或 If-Modified-Since），后者彻底禁止存储。

常见错误是只在 HTML 里加 —— 这对图片资源完全无效，因为图片是独立 HTTP 请求，不受页面 meta 标签影响。

• 后端需为图片资源（如 /api/avatar、/uploads/photo.jpg）单独设置响应头
• Nginx 示例：

  location ~* \.(jpg|jpeg|png|gif)$ {
    add_header Cache-Control "no-store, no-cache";
  }

• Node.js（Express）示例：

  app.get('/dynamic-avatar', (req, res) => {
    res.set('Cache-Control', 'no-store');
    res.sendFile(avatarPath);
  });

前端用时间戳或随机参数绕过缓存

当无法修改服务器响应头（如第三方图床、CDN 静态资源、老旧 CMS），只能靠 URL 变更触发新请求。核心是让每次请求的完整 URL 不同，浏览器就会当作新资源加载。

注意：不能只改参数值（如 ?t=123），必须确保参数实际变化；也不能用固定值（如 ?v=1.0），否则失去效果。

• 最稳妥的是用毫秒级时间戳：src="photo.jpg?t=" + Date.now()
• Vue 模板中可写：:src="'photo.jpg?t=' + new Date().getTime()"
• React 中建议封装成 hook 或 useMemo 避免重复生成：const src = `${baseSrc}?t=${Date.now()}`（注意：不要在 render 中直接调用 Date.now()，否则每次渲染都变，可能引发重绘）
• 避免用 Math.random()：服务端或中间代理可能忽略随机参数，且不利于调试

fetch() 加 cache: 'reload' 对图片无效

有人试图用 JavaScript 的 fetch() 加 cache: 'reload' 重新拉取图片再设给 ，这是徒劳的。原因有二：

• fetch() 的缓存策略只影响该次 fetch 请求本身，不改变后续 的行为
• 即使你把 fetch 到的 blob 转成 URL（URL.createObjectURL()），浏览器仍可能对原始图片 URL 缓存，下次直接从内存/磁盘读，不发请求
• 真正要刷新显示，必须让 的 src 属性值变更，否则浏览器不会重新解码和渲染

Service Worker 干预图片请求需谨慎

如果你已注册 Service Worker，它可能拦截所有图片请求并按自己的逻辑缓存（比如用 cache.match() 返回旧版本）。这时即使 URL 没变，也可能返回过期资源。

关键点在于 SW 的匹配逻辑和缓存键设计：

• 检查 SW 中是否对 image/* 类型做了无条件 cache.match()
• 若需跳过缓存，可在 fetch 事件中判断 URL 后缀，并显式调用 fetch(event.request, { cache: 'reload' })
• 更安全的做法是：对动态图片（如头像、仪表盘图表）使用带版本号的 URL，并在 SW 中排除这些路径，不缓存它们

实际中最容易被忽略的是：同一张图片被多个地方引用（如 CSS background-image、、），只改一处的 URL 并不能保证全部刷新。必须统一控制来源，或确保所有引用都携带一致的缓存破坏参数。