onerror内联写法是唯一可靠路径，必须用并确保备用图高可用，否则将导致浏览器卡死、内存暴涨。
onerror 循环不是写法“不够优雅”的问题，是浏览器会真实卡死、内存暴涨、DevTools 崩溃的硬性故障。必须从事件绑定方式、备用图可靠性、触发边界三方面同时堵住。
onerror 内联写法是唯一可靠路径
动态绑定 img.onerror = handler 或 addEventListener('error', ...) 在 Safari 15.6、旧版 Edge、部分安卓 WebView 中根本不会触发——首屏图片失败时 JS 还没执行，兜底已经失效。服务端渲染（SSR）输出的 HTML 必须带内联 onerror，否则用户第一眼看到的就是空白或破图。
关键点：
- 只信任
<img src="a.jpg" onerror="this.src='fallback.png'; this.onerror=null" alt="HTML onerror循环导致页面卡顿如何优化" >这种写法 -
onerror不冒泡，document.addEventListener('error')默认捕获不到，除非手动加{ capture: true }并检查e.target.tagName === 'IMG' - 框架里写的
@error或onError最终也得落到 DOM 属性上，别以为封装层能绕过这个限制
备用图路径错误是循环根源，不是 fallback 逻辑问题
80% 的卡顿不是因为没写 this.onerror=null，而是 fallback.png 本身也 404。浏览器加载失败后再次进入 onerror，形成无限递归。控制台可能来不及打印错误，页面已无响应。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 绝对不要用相对路径拼错的
./placeholder.jpg或空值src=""；备用图必须走 CDN 或同域高可用地址 - 更稳妥写法：
onerror="if (!this.src.includes('fallback')) this.src='/assets/fallback.svg'; this.onerror=null" - 终极兜底用内联 SVG：
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi...，彻底规避路径风险
onerror 根本不触发的常见场景要提前排除
反复检查 onerror 却看不到效果？大概率它压根没机会运行。这个事件只对“请求发出后失败”有效，以下情况完全不触发：
-
src为空、src=""、src=" "：浏览器不发请求，直接跳过 - CORS 阻塞（如外链图床未配
crossorigin）：控制台报Blocked by CORS policy，但onerror不触发 - 服务器返回 200 + 兜底页（如某些 CDN 对 404 自动返回默认图）：请求成功，不算“加载失败”
- 本地开发用
file://协议双击打开：90% 的“失败”其实是协议限制导致路径解析错乱，换python3 -m http.server就立刻正常
真正难处理的是那些既不触发 onerror、又不显示图片的边缘 case——比如图片文件头正常但数据截断，不同浏览器行为不一致。这时候不能只靠一个属性兜底，得配合 <picture></picture> 格式降级、服务端返回真实可用资源、以及首屏图片禁用懒加载等组合策略。单点优化永远挡不住所有异常流。
