onerror="this.src='fallback.png'; this.onerror=null;"是唯一正确写法，因备用图加载失败会触发无限递归导致页面卡死，必须立即清除事件处理器且顺序不可颠倒。
onerror="this.src='fallback.png'" 为什么卡死页面
因为备用图本身也加载失败时，onerror会再次触发，形成无限递归。浏览器不会自动终止这个过程，内存持续增长，DevTools 可能直接崩溃，用户看到的是页面假死或白屏。
这不是理论风险——真实线上环境里，CDN 故障、路径写错、相对路径解析失败、甚至 fallback 图被误删，都足以触发它。
- 内联写法中，
this.src赋值后若新 URL 返回 404，事件立刻重入 - 旧版 Safari、部分安卓 WebView 对
onerror触发更敏感，循环更快 - 控制台通常不报错，只看到 CPU 占用飙升，排查成本高
必须立即切断 this.onerror 的执行顺序
this.onerror = null 不是可选补丁，是强制安全边界。它必须出现在赋值语句之后、同一行内，且不能被逻辑条件包裹（比如 if 块里延迟执行）。
常见错误写法：onerror="if (!this.src.includes('fallback')) this.src='fallback.png'; this.onerror=null" 看似加了判别，但第一次触发时 this.src 还是原始 URL，条件成立；一旦 fallback 图也 404，第二次触发时 this.src 已变成 fallback.png，条件不成立，this.onerror=null 就不执行，死循环照旧。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 正确写法只有这一种：
onerror="this.src='fallback.png'; this.onerror=null;" - 分号不能省，否则 JS 解析出错，整个内联脚本失效
- 顺序不能颠倒：先赋值再清空，否则清空后下一次失败就无 handler 可调
为什么全局监听 window.error 更适合动态图片
静态 HTML 中给每个 <img> 加 onerror 属性还能控住，但 React/Vue 渲染、CMS 动态插入、瀑布流懒加载等场景下，元素是 JS 创建的，内联属性容易漏绑或拼错，且无法统一管理重试策略。
window.addEventListener('error', handler, true) 在捕获阶段监听所有资源错误，能覆盖 <img>、<script></script>、<link>，且不依赖 DOM 是否已存在。
- 必须传第三个参数
true，否则 script 错误收不到（它不冒泡） - 判断是否为图片错误：用
e.target.tagName === 'IMG' && e.target.src - 避免误伤：加
!(e instanceof ErrorEvent)排除 JS 运行时错误 - 重试前必须先设
e.target.src = ''，否则浏览器可能直接返回缓存的 404 响应
fallback 图路径不可靠是循环的隐藏源头
很多人写了 this.onerror=null 还翻车，根本原因是 fallback 图本身不可访问：路径写成相对路径却没配 <base>，或 fallback 图放在 CDN 上但主站走本地开发服务器，又或用了 file:// 协议导致跨域限制。
真正可靠的 fallback 只有两类：绝对 URL（带协议和域名）、base64 内联图。相对路径在微前端、Electron、PWA 等多环境部署中极易失效。
- 测试 fallback 图是否真能加载：直接粘贴到浏览器地址栏敲回车
- 避免用
./fallback.png，改用/static/fallback.png或完整 URL - alt 文本要语义化，比如按钮图标 fallback 时写
alt="用户头像，加载失败"，不是 “图片”
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
