图片管理需构建可维护链路：统一路径规范防漂移、onerror批量监控加载失败、srcset+sizes响应式适配、CSS Grid替代flex布局图册。
图片管理不是“把图塞进文件夹再贴个 <img>”就完事的事。项目越往后迭代，路径错乱、缓存不更新、尺寸失控、加载失败无感知这些问题就会批量爆发——尤其当多人协作或频繁上线时。真正提升维护效率的关键，在于让图片行为可预测、可定位、可批量干预。
用相对路径 + 统一入口目录避免路径漂移
本地开发时 src="images/logo.png" 能跑，部署到子目录如 /admin/ 下就 404，根本原因是路径计算基准变了。浏览器始终以当前 HTML 文件所在位置为起点解析相对路径，不是以项目根目录或 JS 入口为准。
- 所有图片路径统一从 HTML 文件所在目录出发写，禁用
./和../混用（比如有的写images/a.jpg，有的写../assets/b.png） - 静态资源集中放在
assets/img/目录下，HTML 中一律用src="assets/img/icon-home.svg" - 构建工具（如 Vite、Webpack）里配
public或assets目录时，要确认它是否在最终产物中保留原结构；否则运行时路径会断
给 <img> 加 onerror 并批量检测失败项
图片挂了不报错，只留一个 alt 文字或空白区域，是最难排查的线上问题之一。靠肉眼点开每个页面检查不现实，得让失败本身“发声”。
- 单张图加降级：
<img src="photo.jpg" onerror="this.src='assets/img/placeholder.svg'; this.title='加载失败: photo.jpg';"> - 开发阶段快速扫雷：在控制台执行
Array.from(document.images).filter(i => i.naturalWidth === 0).map(i => i.src)，直接列出所有未加载成功的 URL - 禁止用空
onerror（如onerror=""），它不会触发，也不会 fallback，纯属摆设
用 srcset + sizes 减少无效请求和维护负担
一张 2000px 宽的图扔给手机加载，既拖慢首屏，又浪费带宽。更麻烦的是——每次换图都要手动改 N 个尺寸版本的文件名和路径，极易漏掉某个 srcset 条目。
立即学习“前端免费学习笔记（深入）”；
- 基础写法：
<img src="cat-800.jpg" srcset="cat-400.jpg 400w, cat-800.jpg 800w, cat-1200.jpg 1200w" sizes="(max-width: 768px) 100vw, 50vw" alt="猫"> -
sizes值必须匹配 CSS 中图片容器的实际宽度逻辑，否则浏览器选错源；比如容器是width: 33%，但sizes写成50vw，就会多下一次大图 - 构建时用脚本自动生成多尺寸图并注入
srcset（如 Sharp + Rollup 插件），比人工维护安全得多
用 CSS Grid 管理图册布局，别碰 flex-wrap
图册类页面（如后台素材库、产品画廊）一旦用 display: flex; flex-wrap: wrap，就会出现最后一行对不齐、间隙忽大忽小、图片高度不一致导致整行塌陷等问题——这不是 bug，是 flex 一维布局的天然限制。
- 改用 Grid：
.gallery { display: grid; grid-template-columns: repeat(auto-fit, minmax(280px, 1fr)); gap: 16px; } - 每张图必须包裹在
<figure>里，<figcaption>放标题或操作按钮，避免块级元素撑满整行 - 图片高度不一致？加
aspect-ratio: 4/3或用object-fit: cover+ 固定容器高，别依赖height属性硬拉伸
最常被忽略的一点：图片管理的终点不是“能显示”，而是“出问题时你能 10 秒内定位到哪张图、哪个路径、哪次发布引入的变更”。路径规范、错误监听、响应式源管理、布局机制——这四件事串起来，才构成可维护的图片链路。其他花哨功能都是锦上添花，这里没做扎实，后续所有优化都会打滑。
