浏览器是否缓存图片由服务器响应头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 并不能保证全部刷新。必须统一控制来源，或确保所有引用都携带一致的缓存破坏参数。
