background-image 本身不触发 onerror，因其为 CSS 属性，浏览器不派发加载事件；需用 new Image() 手动监听 onload/onerror 实现检测与降级，多层 url() 会同时请求而非静默 fallback。
background-image 本身不触发 onerror
这是最常被误解的前提：background-image 是 CSS 属性，浏览器不会为它抛出 JavaScript 错误事件，onerror 在 <div style="background-image: url(...)"> 上完全无效。写 <code>onerror="..." 不会报错，但也不会执行——它只是被忽略的无效属性。
所以根本不存在“背景图 onerror 死循环”这回事。真正卡死或无限重试的，几乎全是误把 <img alt="HTML怎么防止背景图加载失败导致的onerror死循环" > 的逻辑套用到了 <div> 或其他元素上。
<h3>想监听背景图失败？得用 Image() + 手动控制</h3>
<p>要感知一张背景图是否加载失败，必须主动创建 <code>Image 实例并监听其 onload/onerror，不能依赖 DOM 元素本身的事件。
- 先创建
const img = new Image()，再赋值img.src = 'https://example.com/bg.jpg' -
img.onerror触发时，手动设置element.style.backgroundImage = 'none'或回退到纯色：element.style.backgroundColor = '#eee' - 务必在
img.onload中调用clearTimeout(timeoutId)，否则超时 fallback 可能和真实加载结果冲突 - 推荐超时设为
5000，太短对弱网不友好，太长用户等待感强
为什么 background-image 多层声明也不“兜底”
CSS 的 background-image: url(a.jpg), url(b.jpg) 不是“a 失败就用 b”，而是**同时加载 a 和 b**，然后按顺序叠在一起渲染。如果 a.jpg 404，浏览器仍会发起 b.jpg 请求，但视觉上你可能只看到 b.jpg（取决于尺寸和 background-position），也可能啥都看不到——因为两图都参与绘制，没有“失败跳过”逻辑。
立即学习“前端免费学习笔记（深入）”；
真正静默 fallback 的写法只有：
-
background-image: url('real.jpg'), linear-gradient(#f0f0f0, #e0e0e0);—— 第二层是纯 CSS，永不失败 -
background-image: url('real.jpg'), url('data:image/svg+xml,%3Csvg%3E%3C/svg%3E');—— 第二层是内联 data URL，无网络请求
注意：逗号分隔的多个 url() 都会触发请求，别指望靠它省流量或防失败。
动态设置 background-image 时最容易漏的三件事
用 JS 动态改 element.style.backgroundImage 后，很多人以为万事大吉，其实还有三个隐性风险点：
- 路径没转义：含空格或括号的 URL 必须用引号包裹，正确写法是
element.style.backgroundImage = "url('bg (1).jpg')"，漏引号会导致整个声明失效 - 相对路径解析错乱：JS 设置的 URL 按当前页面 URL 解析，不是按 CSS 文件位置；开发时用
file://协议会直接指向系统根目录，必须用 Live Server 启服务 - 未预加载 fallback 图：如果 fallback 是个远程 SVG，首次触发
onerror时再去拉取，会有明显延迟白屏；应提前执行new Image().src = 'fallback.svg'
背景图失败不可见，但它的影响是真实的：布局塌陷、交互区域错位、用户以为功能挂了。比起 <img alt="HTML怎么防止背景图加载失败导致的onerror死循环" > 的裂图图标，它更难被发现，也更需要主动验证和兜底。
