onerror无限循环问题可通过this.onerror=null阻断：<img src="broken.jpg" onerror="this.onerror=null; this.src='fallback.jpg';">，顺序不可颠倒；批量场景推荐JS统一监听+dataset控制；治本需CI校验、构建分析与SSR预检。
onerror 触发后再次加载失败图片会无限循环
直接在 img 标签写 onerror="this.src='fallback.jpg'" 是最常见写法，但一旦 fallback.jpg 也加载失败，onerror 会再次触发，导致重复赋值、重复请求、无限重试甚至页面卡顿。
用 onerror 自身设为 null 阻断后续触发
核心思路是：只允许 fallback 执行一次。在错误回调里先清除自身的 onerror 处理函数，再替换 src：
<img src="broken.jpg" onerror="this.onerror=null; this.src='fallback.jpg';">
-
this.onerror=null必须放在this.src=...前，否则若 fallback 再失败，仍会触发原 handler - 这个写法兼容所有现代浏览器，包括 IE9+
- 不要写成
onerror="this.src='fallback.jpg'; this.onerror=null"—— 顺序反了就白干
用 JavaScript 统一管理图片加载失败（推荐用于批量场景）
当页面有多个图片或需要统一 fallback 行为时，内联 onerror 很难维护。更稳妥的方式是用脚本监听并接管：
document.querySelectorAll('img[data-fallback]').forEach(img => {
img.addEventListener('error', function() {
if (!this.dataset.loaded) {
this.dataset.loaded = 'true';
this.src = this.dataset.fallback;
}
});
});
- 用
dataset.fallback存备用地址，避免硬编码；用dataset.loaded标记是否已尝试 fallback，防重复 - 不依赖
onerror属性，完全由 JS 控制生命周期，便于后续加日志、监控或降级策略 - 注意：如果图片初始
src为空或非法（如src=""），部分浏览器可能不触发error事件，需额外判断
服务端或构建时预检图片路径更治本
前端兜底只是补救。真正减少 onerror 触发，得从源头控制：
立即学习“前端免费学习笔记（深入）”；
- CI 流程中加入图片路径校验（比如用
sharp或file-exists检查public/下资源是否存在） - Webpack/Vite 构建时，对
require('./xxx.jpg')类引用做静态分析，缺失则报错 - 服务端渲染（SSR）中，
img渲染前先fs.stat检查文件，不存在则直接输出 fallback 的src，连onerror都不注册
循环问题看似小，但暴露的是资源治理松散——一旦 fallback 图片本身也部署遗漏，整个降级链就断了。
