HTML图片版本控制核心是URL变更+构建注入+存储校验三者配合：必须用内容哈希（如avatar.a1b2c3.jpg）或根相对路径确保URL唯一性，构建时固化进HTML，禁止运行时拼接，并与JS/CSS版本强绑定。
HTML 图片资源本身不带版本概念，所谓“版本维护”本质是控制浏览器加载哪个文件、何时加载、如何验证一致性——核心靠 URL 变更 + 构建时注入 + 存储校验三者配合，缺一不可。
图片 URL 怎么加版本标识才真正生效
只改文件内容不改 URL，浏览器永远认不出新图。必须让 URL 本身携带唯一性标识：
- 推荐用内容哈希：服务端上传后返回 avatar.a1b2c3.jpg 这类文件名，前端直接赋值给
img.src；哈希变则 URL 变，缓存自动失效，且无需额外参数 - 退而求其次用查询参数：
img.src = "avatar.jpg?t=" + Date.now()—— 仅限开发或低频更新场景，生产环境慎用，t 参数可能被 CDN 或代理层剥离 - 绝对不要用
Math.random()做参数：它破坏 HTTP 缓存复用，同一张图每次请求都走网络，浪费带宽 - 路径必须统一为根相对路径（
/images/avatar.jpg）或绝对 URL，避免./images/在子路由下 404
构建流程里怎么把图片版本和 HTML 绑定
手动改 src 值等于放弃维护。要让版本信息在构建阶段就固化进 HTML：
- Vite/Webpack 中用
import.meta.env.VITE_IMG_VERSION或process.env.IMG_HASH注入变量，再在模板中拼接：<img src="/images/logo.${IMG_HASH}.png"> - 静态站点生成器（如 Hugo、Jekyll）可用内置变量，比如
{{ "logo.png" | fingerprint }}，自动生成带哈希的路径 - 禁止在 JS 运行时读取
package.json或调用fetch("/version.json")拼 URL —— 这个请求可能失败、被缓存、或比图片加载还慢，导致空白 - 如果图片来自 CMS，确保其 API 返回的 URL 已含版本参数（如
?v=20261001），前端不做二次加工
localStorage / IndexedDB 里怎么同步图片版本状态
当图片不只是展示，还参与业务逻辑（如用户头像用于签名、水印图用于导出），本地存储的数据结构就得和图片版本对齐：
立即学习“前端免费学习笔记（深入）”；
- 在
localStorage中存一个键：localStorage.setItem("image_schema_version", "2.1.0")，值必须硬编码在 JS 中，与当前构建版本一致 - 页面启动时比对：
if (localStorage.getItem("image_schema_version") !== CURRENT_VERSION) { clearOldCache(); }，用localeCompare()安全比较语义化版本 - IndexedDB 升级时，在
onupgradeneeded事件里检查并迁移旧图数据（如 base64 字符串需重新压缩、尺寸元信息需补全） - Service Worker 的 cacheName 必须带版本，例如
"images-v2.1.0"，install 阶段预加载新版图片，fetch 时只匹配当前版本 cache
为什么 <meta name="img-version"> 没用
这个标签看起来很“正规”，但实际既不能触发缓存更新，也无法被自动化工具读取：
- 浏览器完全忽略它，CDN 不识别它，构建工具不会基于它做替换，运维查问题时还得开控制台翻源码
- 如果把它当逻辑开关（如
if (meta.content === "2.0") {...}），JS 无法在 DOM ready 前读到它，且容易被 HTML 压缩工具删掉 - 更糟的是，有人把它和图片 URL 混用，比如
<img src="logo.jpg" data-version="2.0">—— data 属性不参与网络请求，对缓存零影响 - 真正该暴露版本的地方只有两个：URL 路径本身、以及构建后写死在 JS 全局变量里的
CURRENT_VERSION
最易被忽略的点是：图片版本必须和 JS/CSS 版本强绑定。一张新图配旧 JS，可能因尺寸计算逻辑变更导致布局错乱；一张旧图配新 CSS，object-fit 行为可能不兼容。所有版本标识得从同一个源头（如 package.json 的 version）生成，否则“版本维护”只是假象。
