静态图片资源管理的关键在于正确引用路径、选择合适格式及优化加载时机：路径需按HTML物理位置计算，区分大小写；优先用WebP并压缩；首屏图禁用lazy，非首屏图须设宽高；CDN与Cache-Control需协同配置。
静态图片资源管理不当，90% 的 404 和首屏加载延迟都源于路径、格式和加载时机这三处。核心不是“放哪”，而是“怎么引用”和“什么时候拉”。
HTML 中 src 路径写错导致本地正常、上线 404
所有 src 和 href 解析基准是 HTML 文件在磁盘上的物理位置，不是浏览器地址栏 URL，也不是你“以为”的目录结构。
- 同级文件直接写
logo.png，别加./logo.png——多打字符还易手误 - HTML 在
/pages/article.html，想引用根目录下/assets/icon.svg，必须写../assets/icon.svg；少一个../就 404 - Linux 服务器大小写敏感：
IMG.PNG≠img.png，Windows 双击不报错，一上生产就挂 - 绝对路径如
/assets/logo.png看似省事，但部署到子路径（如https://example.com/myapp/）时，浏览器仍会去根目录找，必然 404
图片格式选错或没压缩，体积翻倍还模糊
格式不是凭感觉选的：JPG 适合照片，PNG 适合图标和透明图，WebP 是现代首选——同画质下比 JPG 小 30%~50%，比 PNG 小 25%+，且支持透明和动画。
- 别再用 JPG 存 logo 或 UI 图标；也别用 PNG 存 Banner 大图
- 批量转 WebP 后，必须再走一遍无损压缩工具（如 TinyPNG、Squoosh），移除 EXIF、优化编码参数
- 避免“一张图适配所有设备”：用
srcset提供1x/2x版本，让移动端只下载对应分辨率的图 - 响应式图片推荐写法：
<img src="photo-960w.jpg" srcset="photo-480w.jpg 480w, photo-960w.jpg 960w, photo-1440w.jpg 1440w" sizes="(max-width: 480px) 480px, (max-width: 960px) 960px, 1440px">
loading="lazy" 配错反而拖慢首屏渲染
懒加载不是万能开关，加错位置或条件，LCP（最大内容绘制）直接被砍掉 300ms+。
立即学习“前端免费学习笔记（深入）”；
- Hero 图、Logo、主商品图这些首屏关键图，必须去掉
loading="lazy"，否则浏览器压根不优先拉 - 非首屏图片（如列表项头像、文章配图）才加
loading="lazy"，但必须显式声明width和height属性，否则 CLS（布局偏移）飙升 - Safari 15.4 之前不支持
loading="lazy"对<iframe>的作用，旧环境需回退到data-src+IntersectionObserver - 禁用
document.write()插图逻辑——现代浏览器已废弃，执行即清空整个文档流
CDN 和缓存策略没对齐，图片永远不走缓存
CDN 不是“扔上去就加速”，它和浏览器缓存头必须协同生效。单独开 CDN 或单独设 Cache-Control，效果都打折。
- 图片托管到 CDN（如 Cloudflare、阿里云 CDN）后，必须在响应头中设置
Cache-Control: public, max-age=31536000（一年），否则 CDN 节点不缓存，用户每次仍回源 - CDN 控制台启用“自动图像优化”：实时转 WebP、裁剪、压缩，无需改代码
- 禁止给 HTML 文件设强缓存（
Cache-Control: immutable），否则哈希文件路径更新后，旧 HTML 仍会请求过期的main.a1b2c3.js - 字体、SVG 等关键资源建议用
<link rel="preload" as="image" href="logo.svg">提前触发请求，但仅限真正影响首屏的资源
最常被忽略的一点：图片路径写法本身不决定缓存，决定缓存的是 URL 是否稳定 + 服务端响应头是否匹配。哪怕你把 logo.png 改成 logo-v2.png，只要没配好 max-age 和 CDN 缓存规则，浏览器照样不存。
