浏览器对 background-image 的图片 URL 会遵循 HTTP 缓存逻辑，依赖 Cache-Control、Expires 或 ETag 响应头；强制刷新需改请求 URL（如加时间戳）、服务端禁用缓存或用 CSS 变量动态更新，构建工具可自动注入哈希，但需确保 CSS 文件本身也缓存失效。
background-image 的 URL 缓存行为怎么触发的
浏览器对 background-image 使用的图片 URL 会像普通图片一样走 HTTP 缓存逻辑：只要响应头里有 Cache-Control、Expires 或 ETag 有效，且 URL 完全一致，就会直接复用本地缓存，不发新请求。哪怕你替换了服务器上的图片文件，只要 URL 没变，用户就看不到更新。
强制刷新 background-image 的三种实操方式
核心思路是让浏览器认为这是“新资源”，从而绕过缓存。不是清用户缓存，而是改请求本身：
- 在图片 URL 后加时间戳或哈希参数（最常用）：
element.style.backgroundImage = "url('/img/bg.jpg?v=' + Date.now())"; - 服务端配置禁止缓存该路径（适合开发/测试环境）：
Location /img/bg.jpg { add_header Cache-Control "no-cache, no-store, must-revalidate"; } - 用 CSS 自定义属性 + JS 更新（适合动态主题切换）：
:root { --bg-url: url('/img/bg.jpg?ts=1715234890'); } body { background-image: var(--bg-url); } // JS 中更新： document.documentElement.style.setProperty('--bg-url', `url('/img/bg.jpg?ts=${Date.now()}')`);
Webpack/Vite 构建时自动处理 background-image 路径
如果用构建工具，别手动拼 ?v=xxx，容易漏或重复。让打包器自动注入哈希：
- Vite 中，
background-image: url('./bg.jpg')在 CSS 里会被自动重写为带 hash 的路径（如bg.abc123.jpg），前提是图片被当成模块引入 - Webpack 需配
css-loader+file-loader或asset-module，确保url()内路径进入构建流程，否则仍走原始路径、无 hash - 注意：CSS 中写绝对路径
url(/static/bg.jpg)或协议头路径url(https://...)不会参与构建，也就不会加 hash
Chrome DevTools 里验证是否真刷新了
别只靠 Ctrl+F5 或清缓存——那只是强制重载整个页面，不能代表 background-image 请求是否更新。正确验证步骤：
立即学习“前端免费学习笔记（深入）”；
- 打开 DevTools → Network 标签页 → 勾选
Disable cache（仅用于调试） - 过滤
Img或输入图片文件名，看请求的Response Headers中是否有cache-control: no-cache或200 OK（非304 Not Modified） - 关键看
Request URL是否含变动参数（如?v=1715234890），以及Size列是否显示真实字节数而非(memory cache)
最容易被忽略的是：CSS 文件本身也被缓存，如果背景图 URL 写死在未更新的 CSS 里，加参数也没用——得确保 CSS 文件也带 hash 或禁用缓存。
