响应式图片在部分国产浏览器中失效，核心是不支持、误解析、被拦截三层原因；需验证picture标签识别、sizes/srcset解析、fallback强制兜底及懒加载回退方案。
排查响应式图片在部分国产浏览器中失效，核心是抓住“不支持、误解析、被拦截”三个层面——不是所有国产浏览器都用标准 Chromium 内核，很多仍基于老旧 Blink 或定制 WebKit，对 <picture></picture>、srcset、sizes 的支持存在断层或静默降级。
先确认是否真“失效”，还是根本没触发
国产浏览器（如 QQ 浏览器、UC、360、搜狗）常默认启用“兼容模式”或“极速模式”双内核，实际渲染可能走 IE 兼容内核（Trident）或阉割版 WebKit。别只看控制台有没有报错，要验证：
- 打开开发者工具 → Elements 面板，展开
<picture></picture>，看最终渲染的是哪个<source></source>还是直接 fallback 到了内部的<img> - 在 Console 中执行：
document.createElement('picture').toString()，若返回[object HTMLUnknownElement]，说明浏览器根本不认识<picture></picture>标签，会忽略整个结构 - 检查 Network 面板：加载的到底是 WebP 还是 JPG？如果始终只拉 JPG，可能是
type="image/webp"被完全忽略，而非格式不支持
重点查 sizes 和 srcset 是否被误读
国产浏览器对 sizes 属性解析极不稳定，尤其在 viewport 缩放、横竖屏切换后容易沿用旧值；srcset 若混用 w 和 x 单位，部分内核会整条丢弃（不是选错，是直接不用）。
- 避免写
sizes="100vw"这类笼统值，改用明确断点，例如：sizes="(max-width: 750px) 100vw, (max-width: 1200px) 50vw, 33vw" -
srcset中只用一种单位：移动端适配优先用w（如320w, 750w, 1200w），不要混写1x, 2x - 用 Chrome DevTools 模拟 UA（如设为 “QQBrowser/10.4”），再配合 Network 面板观察真实请求宽度，比猜更可靠
兜底逻辑必须显式、强制、无依赖
国产浏览器对 <picture></picture> 的 fallback 行为不统一：有的跳过所有 <source></source> 直接渲染 <img>，有的则因 <img> 缺 src 而留白。
-
<img>标签必须带src，且不能是空字符串或仅占位图（如data:）；推荐用最小 JPG（1x1像素）+onerror替换，例如：<img src="/img/blank.jpg" onerror="this.src='/img/fallback.jpg'"> - 不要依赖
media属性做格式判断，Safari 13 以下和多数国产内核对media="(min-width: 1px)"支持也不稳；把 WebP 和 AVIF 的<source></source>放最前面，JPG 放最后，靠顺序兜底 - 给
<img>显式加width和height（如width="750" style="max-width:90%"），否则部分内核连占位空间都不预留，导致布局塌陷、图片“闪入”
懒加载与格式探测要分开处理
国产浏览器普遍不支持 loading="lazy"（X5 内核全版本静默忽略），且对 canPlayType 类型探测也常返回空字符串，不能靠 JS 判断是否支持 WebP。
- 用特性检测代替 UA 判断：
if ('supports' in HTMLPictureElement)不可靠，改用const webp = new Image(); webp.onload = webp.onerror = () => { ... }; webp.src = 'data:image/webp;base64,UklGRiQAAABXRUJQVlA4IBgAAAAwAQCdAgSSAAf480f//7Dv/w=='; - 懒加载必须回退 IntersectionObserver，且
rootMargin至少设"300px"（国产浏览器视口计算偏慢，“刚进视口才加载”大概率白屏） - 不要在
<source></source>上写loading="lazy"—— 它只对<img>生效，且在 X5 中无效
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
