onerror无限触发的根本原因是备用图加载失败后浏览器重复进入同一错误处理逻辑，必须在赋值src后立即执行this.onerror=null并确保备用图路径绝对可靠。
onerror无限触发的根本原因是什么
根本就不是事件本身有问题，而是备用图加载又失败了，浏览器会再次进入同一个 onerror 处理逻辑——没有手动切断，它就会反复执行赋值、再失败、再赋值，直到内存暴涨或标签页卡死。
这种死循环不报错，也不中断，只表现为页面假死、CPU飙升、图片区域持续空白或闪烁。它只在真实网络请求失败时触发，对空 src、CORS 阻塞、服务器返回 200 的兜底 HTML 页面完全不响应。
-
this.onerror=null不是“建议”，是硬性前置动作：必须紧接在this.src=...赋值之后，且中间不能有异步操作或条件分支 - 备用图路径必须绝对可靠：相对路径（如
./fallback.png）拼错、CDN 下线、权限变更都会导致二次失败 - 内联 SVG base64 是最稳的 fallback：像
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi...这种写法，彻底绕过网络请求环节
静态 HTML 中 onerror 的安全写法
内联写法看似方便，但顺序和语法容错率极低。写错一个分号、漏一个 null、把 this.onerror=null 放在赋值前，都会失效。
- 正确格式只有一种：
onerror="this.src='https://cdn.example.com/placeholder.svg'; this.onerror=null;" - 路径必须是绝对 URL 或 base64；不能用
./、../、/assets/这类依赖当前路径解析的写法 - 如果备用图也要支持主题色或尺寸适配，优先用内联 SVG，而不是 PNG/JPEG——前者无请求、无跨域、可缩放
- 不要在
onerror里调用外部函数（如onerror="handleError(this)"），函数未定义或执行出错会导致事件静默丢失
动态插入的 <img> 怎么绑定 onerror 才不丢事件
JS 创建后直接 appendChild()，再补 onerror 是无效的：图片加载失败可能发生在 DOM 插入瞬间，事件早已触发并错过。
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
立即学习“前端免费学习笔记（深入）”；
- 必须在设置
src之前，就用addEventListener('error', handler)绑定 - handler 内第一行就得写
img.onerror = null或event.target.onerror = null，否则移除监听器不彻底 - 避免用
img.onerror = function() {...}形式——后续重新赋值会覆盖，且无法用removeEventListener解绑 - 若需重试逻辑（比如换 CDN 域名），先清空
event.target.src = ''，再赋新值，否则浏览器可能直接读缓存的 404 响应
React 里 onError 回调为什么还触发多次
React 的 onError 是合成事件，但底层仍依赖原生 error 事件。很多人只写了替换 src，却忘了清除事件处理器，导致默认图加载失败时，React 会再次调用该回调。
- 必须在回调第一句就写：
currentTarget.onerror = null - 不要用箭头函数包裹后再赋值给
onError，比如onError={() => { ... }}，每次 render 都新建函数，无法稳定控制事件流 - 如果默认图也来自变量（如
fallbackSrc），确保该变量在组件生命周期内始终可用，不能是异步获取中为空的 state - 服务端渲染（SSR）场景下，首屏
img的src应为真实可访问地址，而非等待 JS 水合后才注入——否则客户端首次 error 已发生，onError 来不及绑定
真正容易被忽略的是：onerror 只管“请求发出后失败”，它不管 CORS、空 src、HTML 片段兜底、甚至 fetch API 报错。这些都得靠其他机制兜底，比如 <picture> 控制格式兼容，loading="lazy" 配合 data-src 做懒加载降级，以及服务端确保首屏资源高可用。单靠 onerror 一条路，永远撑不起鲁棒的图片链路。
