复杂图片必须分层设计降级路径：格式→尺寸→网络条件→渲染能力；用实现格式与尺寸双降级，严格按type顺序、media括号、srcset宽度描述符、content-type校验执行，首屏关键图禁用lazy，服务端需配合save-data头与mime区分缓存。
复杂图片（如横幅、轮播图、带透明通道的图标、多条件适配的 Banner）不能靠单一 src 或仅加 loading="lazy" 应对——必须分层设计降级路径：格式 → 尺寸 → 网络条件 → 渲染能力，漏掉任一层，就可能在 Safari 旧版、微信 WebView 或弱网下白屏。
用 <picture></picture> 做格式与尺寸双降级，顺序和 type 缺一不可
复杂图片往往要同时解决“浏览器支不支持 WebP/AVIF”和“手机该加载多大尺寸”两个问题。<picture></picture> 是唯一能原生协同处理这两者的 HTML 方案，但必须严格按规则写：
-
<source></source>必须从现代到兼容排列：先type="image/avif"，再type="image/webp"，最后<img src="xxx.jpg">；浏览器匹配第一个可加载的，错序等于废掉高级格式 - 每个
<source></source>的media属性必须带括号，例如media="(min-width: 1200px)"，写成media="min-width: 1200px"会被完全忽略 -
srcset里必须含宽度描述符（如banner-1920.jpg 1920w），只写x描述符（如2x）会导致尺寸误判，小屏也可能拉取桌面图 - 服务端返回 AVIF 时，
Content-Type必须是image/avif，Nginx 或 CDN 若错误设为application/octet-stream，Chrome 会静默跳过该<source></source>
关键图禁用懒加载，首屏必须靠 src 直接加载
轮播主图、品牌横幅这类元素一旦白屏，用户第一印象就崩了。别信“所有图都 lazy”的教条：
- 首屏内图片一律不加
loading="lazy"，src必须指向真实可用资源（如 SSR 渲染出的 800px JPG），不能是占位图或空值 - 若需模糊占位（LQIP），用 base64 内联到
src中：src="data:image/svg+xml;base64,..."，确保断网也能显示结构 - 微信 iOS WebView 对
loading="lazy"支持极差，且不触发error事件，首屏图若依赖它，大概率在公众号里直接消失
避免 CSS 导致降级失效的三个硬坑
很多降级逻辑写得再细，也会被一行 CSS 彻底绕过——这些样式在 JS 未执行、断网、或低版本浏览器中照常生效：
-
display: none在 Safari 和多数安卓 WebView 中会让IntersectionObserver完全不监听该元素，即使之后display: block也不会补触发；改用opacity: 0或visibility: hidden - 容器设了
overflow: hidden且图片初始位置超出裁剪区？iOS Safari 会判定其“不可见”，拒绝加载——加rootMargin: "100px"可缓解，但不如提前预留空间 - 没设宽高或
aspect-ratio，图片加载后强制重排，视觉跳动会被用户感知为“加载失败”；正确做法是用padding-top百分比占位，或服务端注入内联width/height
服务端配合：Save-Data 头 + MIME 类型校验是隐藏关键点
纯前端降级只能兜住浏览器能力差异，但对“用户开了省流量模式”或“CDN 缓存错乱”无能为力：
- 后端需检查请求头中的
Save-Data: on，对匹配请求返回更小尺寸、更低质量的 JPG（如 640px + -q 65），而不是只靠前端sizes切换 - CDN 缓存策略必须区分
Accept头：image/webp请求缓存 WebP 版本，image/jpeg请求缓存 JPG 版本，混用会导致降级失效 - 本地开发调试时，用 DevTools → Network → 查看 AVIF/WebP 请求的
Response Headers，确认Content-Type与<source type></source>完全一致，这是最容易被忽略的线上故障点
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
