IE8/IE9中直接写src="x.svg"会白屏，因IE8完全不支持SVG且跳过解析，IE9+若MIME类型非image/svg+xml或路径含查询参数则静默失败、onerror不触发；最稳方案是用img标签配合onerror切换PNG并立即切断事件链。
图片占位图降级不是“加个 fallback 就完事”，而是必须让 src 始终可加载、
为什么直接写 src="x.svg" 在 IE8/IE9 会白屏
IE8 完全不支持 SVG，连解析都跳过；IE9+ 虽支持，但若后端返回的 MIME 类型不是 image/svg+xml，或路径带查询参数（如 icon.svg?v=1），也会静默失败——onerror 不触发，控制台无报错，只留空白。
- 最稳做法：
<img src="icon.svg" onerror="this.src='icon.png'; this.onerror=null" alt="HTML图片占位图怎么降级？SVG替代方案一览" > - 不要依赖 JS 动态绑定
onerror：Safari 和旧 Edge 中大概率不捕获首次错误 - 确保
icon.png是真实存在的静态资源，不能是相对路径错误的地址（如./images/icon.png在嵌套路由下可能 404）
<picture></picture> 里用 SVG 作降级源是否可行
不行。<source></source> 的 type 属性只接受标准 MIME 类型，type="image/svg+xml" 是合法的，但浏览器不会把它当作“现代格式优先尝试”的一环——SVG 不是渐进式编码格式（不像 AVIF/WebP/JPG 那样有明确解码优先级），且多数浏览器对 <source type="image/svg+xml"></source> 的支持行为不一致，Safari 会跳过，Chrome 可能请求但不渲染。
- 正确姿势：把 SVG 当作最终兜底，放在
<img alt="HTML图片占位图怎么降级？SVG替代方案一览" >里，而不是<source></source> - 例如：
<picture><source type="image/webp" srcset="a.webp"><img src="a.svg" alt="..."></source></picture>—— 这里a.svg是语义完整、独立可访问的最终 fallback - 如果
a.svg本身失效，仍需内联onerror补救：<img src="a.svg" onerror="this.src='/placeholder.svg'; this.onerror=null" alt="...">
用内联 SVG 做占位图时怎么防失效
内联 SVG（直接写 <svg>...</svg>）不发网络请求，天然规避路径和 CORS 问题，但容易因 viewBox 错、尺寸失配、filter 模糊溢出导致视觉异常或布局抖动。
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
立即学习“前端免费学习笔记（深入）”；
-
viewBox必须与目标图宽高比严格一致，否则拉伸变形 - 禁用抗锯齿：
shape-rendering="crispEdges"防止多边形边缘发虚 - 模糊层用
<fegaussianblur stddeviation="2"></fegaussianblur>，超过 3 容易糊成色块 - 避免在
<svg></svg>外再套容器做尺寸控制——它自己就得撑满预期宽高 - 动态替换真实图时，用
replaceWith()替代innerHTML = ...，防止事件监听器丢失
SQIP 占位图要不要 base64 编码
不要。SQIP 的核心价值是小体积（~1–3 KB）、可缩放、DOM 可控。一旦转成 data:image/svg+xml;base64,...，就失去样式干预能力（无法用 CSS 控制 fill 或 filter），且 base64 解码会阻塞 HTML 解析。
- 直接内联原始 SVG 字符串，保留
<defs></defs>和<filter></filter>结构 - 所有
fill值用十六进制（如#e0d6c9），避免命名色（如lightgray）在部分 UA 下 fallback 失败 - 如果担心首次渲染慢，可配合
loading="eager"强制预加载，但别加fetchpriority="high"——对内联内容无效
真正麻烦的从来不是“怎么写”，而是“谁来保证所有图片的 src 在部署后依然指向一个真实可用的 URL”。CDN 路径变更、构建产物哈希更新、路由重写规则调整……任何一个环节漏掉，onerror 就成了最后一道脆弱防线。
