onerror对background-image完全无效，它仅适用于等带src的标签；CSS背景图加载失败浏览器静默忽略，无事件触发，须改用+onerror或JS预检降级。
background-image加载失败时onerror根本不会触发
HTML 元素的 onerror 属性对 background-image 完全无效——它只作用于 <img alt="HTML背景资源失败后的onerror循环如何处理" >、<script></script>、<link> 这类有明确 src 或 href 的资源标签。CSS 中的 background-image: url(...) 加载失败，既不抛事件，也不触发任何回调，浏览器静默忽略。
常见错误是试图这样写：<div style="background-image: url(banner.jpg)" onerror="this.style.backgroundImage='url(fallback.jpg)'"></div>。这段 onerror 永远不会执行，因为 div 不是资源加载器，background-image 也不是它的属性值来源。
CSS fallback 只能靠多层声明或 JS 主动检测
真正可行的降级路径只有两条：纯 CSS 声明兜底，或用 JS 监听全局 error 并反向定位元素。前者轻量但能力有限，后者灵活但需谨慎设计。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- CSS 方案依赖浏览器按顺序尝试：先写
background-image: url(logo.avif)，再写background-image: url(logo.webp)，最后写background-image: url(logo.png)。但注意：这并非“失败后回退”，而是**并行声明、由浏览器选第一个支持且可解码的**；如果最后一个也 404，就彻底白屏，无 fallback - 更可靠的是用
:has()伪类（Chrome 105+、Safari 15.4+）做视觉占位：div:not(:has(img[src])) { background-color: #f0f0f0; }，但它无法感知background-image本身，只能配合<img alt="HTML背景资源失败后的onerror循环如何处理" >占位逻辑使用 - JS 检测必须绕过“无法监听”的限制：监听
window.addEventListener('error', e => {...}, true)，然后检查e.target是否为<img alt="HTML背景资源失败后的onerror循环如何处理" >；若该<img alt="HTML背景资源失败后的onerror循环如何处理" >和目标 div 存在绑定关系（如共享data-bg-for="hero"），才去修改 div 的样式
动态设置 background-image 时如何防重复请求和死循环
如果你是用 JS 动态赋值 element.style.backgroundImage = 'url(...)'，那失败完全不可捕获——没有事件、无状态反馈、也无法重试。必须改用 <img alt="HTML背景资源失败后的onerror循环如何处理" > + object-fit 替代：
立即学习“前端免费学习笔记（深入）”；
- 把背景图换成
<img src="..." alt="" class="bg-cover">，加onerror="this.src='/assets/placeholder.svg'; this.onerror=null;" - CSS 控制：
.bg-cover { position: absolute; inset: 0; width: 100%; height: 100%; object-fit: cover; } - 这样既能用原生
onerror保底，又避免了路径拼错、CORS 静默失败、服务端返回 200 占位图等所有 CSS 背景图无法应对的场景
真正的难点不在“怎么换图”，而在于**你永远不知道 background-image 失败了没**——它不报错、不触发事件、不改变 DOM，连 DevTools 的 Network 面板都可能不显示失败请求。所以，别试图给 CSS 背景加 onerror，从一开始就不该让它承担关键视觉职责。
