相对路径+srcset+WebP+loading="lazy"可解决80%图片浪费问题；相对路径以HTML为基准，部署子路径不404；srcset列图源宽度，sizes告知渲染宽度，缺一不可；WebP压缩体积，lazy延迟非首屏加载，二者叠加才真正省带宽。
直接用相对路径 + srcset + WebP 格式，再配 loading="lazy"，就能解决 80% 的图片资源浪费问题。硬套 CDN、建 /public 目录或强求“静态资源分离”，反而容易引入路径错乱和构建时丢失文件。
为什么相对路径比绝对路径更可靠
浏览器解析 src 时，永远以当前 HTML 文件所在目录为基准。部署到子路径（比如 https://example.com/app/）时，/assets/logo.png 会强制去根目录找，404 是必然结果；而 ./assets/logo.png 或 assets/logo.png 会自动跟随 HTML 位置调整。
- 所有路径里别带空格或中文——URL 编码后难调试，也容易在 Windows 和 Linux 间出兼容问题
-
./前缀多数时候冗余，logo.png和./logo.png效果一样，但多打字符易出错 - 如果 HTML 在
/pages/about.html，图片在/assets/icon.svg，就写../assets/icon.svg，别幻想“统一放根目录”能省事
srcset 和 sizes 不是炫技，是防止移动端加载 3MB 大图
只写 src 等于把所有设备都喂同一张图。现代浏览器靠 srcset 和 sizes 决定加载哪一版，不发请求、不下载、不解码——这才是真节省带宽。
-
srcset列的是“有哪些图”，比如logo-400w.webp 400w, logo-800w.webp 800w，单位w表示该图源的固有宽度 -
sizes告诉浏览器“这张图在页面里大概占多宽”，比如(max-width: 768px) 100vw, 50vw，浏览器据此匹配最接近的w值 - 没配
sizes时，浏览器默认按100vw算，可能选错高分辨率图——尤其在响应式布局中非常常见
WebP 和 loading="lazy" 必须一起用
WebP 能压掉 30–50% 体积，但若首屏就塞 10 张未压缩的 WebP，仍会阻塞渲染；而 loading="lazy" 对非首屏图跳过初始加载，两者叠加才真正释放带宽。
立即学习“前端免费学习笔记（深入）”；
- 原生
loading="lazy"在 Chrome 76+、Firefox 75+、Safari 15.4+ 支持，老版本需 fallback 到 IntersectionObserver - 必须确保容器有明确高度或占位，否则图片加载时页面会“抖动”——CSS 加
aspect-ratio: 16/9或内联height属性最稳 - 别对
<img>同时设width/height和max-width: 100%，后者会覆盖前者导致比例失真
第三方图片资源别塞进组件模板
像 Bootstrap 图标、CDN 上的字体图标这类资源，必须写死在 index.html 的 <head> 里。塞进 React/Vue 组件模板里，构建工具根本没法在编译期解析变量路径，报错 NG2008: Could not find stylesheet file 是常态。
-
index.html是唯一 HTML 入口，浏览器首次加载它时，这些资源同步拉取，不依赖 JS 执行 - 动态拼接 CDN 地址（如
https://cdn.example.com/v{{version}}/icon.svg）会导致构建失败，直接写死完整 URL - 图标类小图优先用 SVG 内联，比 HTTP 请求更快，也避免跨域或缓存失效问题
最容易被忽略的是 sizes 属性的缺失，以及把 index.html 当普通组件来管理外部资源——这两点会让所有优化努力白费，而且错误不报在控制台，只在 Lighthouse 分数和用户流量账单上体现。
