要找全所有图片引用位置，需覆盖四层：html中/标签、css中background-image（含@media内）、js中字符串拼接路径及data-src等、构建工具如webpack的require()调用；全局搜索src=", url(", background-image等关键词最高效。
直接替换文件名和路径最稳，但漏掉 JS 动态拼接或 CSS 媒体查询里的 background-image 就会“换了一半”。不是所有图片都藏在 <img src=""> 里。
怎么找全所有图片引用位置
浏览器「检查元素」只能看到当前渲染的 DOM，而真实引用可能分散在四层：
-
index.html和其他页面中所有<img src="">、<source srcset=""></source>、<img srcset=""> -
style.css或main.css里所有background-image: url("")，尤其注意@media块内部的重复定义 -
.js文件中用字符串拼接的路径，比如item.id + ".jpg"、src = "images/" + name、data-src属性赋值 - 构建工具配置（如 Webpack 的
require("./assets/banner.jpg")），这类在开发环境不显形，但打包后路径会固化
全局搜索关键词比手动翻更快：src="、srcset="、url("、background-image、data-src、appendChild、innerHTML。
为什么覆盖原文件比改路径更安全
改路径要同步动 HTML、CSS、JS、甚至构建配置，一处漏就断链；覆盖原文件只需确保新图和旧图完全同名、同格式、同大小写、同相对路径层级。
- Windows 下
Product.jpg和product.jpg是同一个文件，Linux 服务器上却是两个——部署后图片 404 往往是这个原因 - 轮播组件（如 Swiper）常靠文件名排序，
slide1.jpg→slide2.jpg，改成hero-01.jpg就乱序 - 懒加载库（如 lazysizes）可能监听
data-src或src变化，路径一变就得重初始化 - 如果必须改路径（比如 CMS 禁止覆盖），记得检查
<picture></picture>中每个<source></source>的srcset，它们各自独立，不是改一个就全换
响应式图片切换失效的三个硬伤
<picture></picture> 和 srcset 不是写了就能切，浏览器加载阶段就决定了用哪张，出错时不会报错，只会静默 fallback 到 <img src="">。
-
<source></source>的media缺括号，比如写成media="max-width: 768px"→ 整条被忽略，浏览器当不存在 -
<source></source>顺序反了：把(max-width: 767px)放最前，宽屏设备永远匹配不上后面的规则 -
<img>没写src或写成自闭合形式<img>→ Safari 16.4 之前直接白屏，连 fallback 都没有
验证方法很简单：开 Chrome DevTools → Network 面板 → 切不同设备尺寸 → 看图片请求的 URL 是否变化，Status 是否为 200。
缓存导致新图不显示，不是模板问题
文件替换了，路径也对，但页面还是旧图——90% 是缓存惹的祸。浏览器、CDN、甚至本地服务（如 Live Server）都会缓存图片资源，尤其当文件名没变时。
- 强制刷新只是清浏览器内存缓存，Ctrl+F5 或 Cmd+Shift+R
- 进 Network 面板勾选 “Disable cache”，再刷新，看图片请求头
Last-Modified是否更新 - 临时加版本参数绕过：把
src="images/banner.jpg"改成src="images/banner.jpg?v=2"（上线前得删掉） - Webpack/Vite 项目要
npm run build后再预览，别只在 dev server 里看
真正耗时的从来不是拖图进文件夹，而是确认哪一层代码在控制这张图的最终来源——HTML？CSS？JS？还是构建时注入的？漏一层，“图换了但没完全换”就是常态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
