列表大量图片变慢主因是每个404触发JS执行与DOM重排，100张图即100次错误处理；备用图二次失败且this.onerror=null未正确设置会导致标签页卡死；应全局捕获error事件、标记已处理图片、用绝对路径或base64备用图，并配合服务端优化减少客户端负担。
为什么列表里大量![]()
会变慢
不是onerror本身慢，而是每个失败请求都会触发一次JS执行+DOM重排，100张图同时404，就等于100次独立错误处理流程。更麻烦的是：备用图再失败，this.onerror=null没写对，就会卡死标签页。
避免重复绑定和无效触发
动态渲染的列表（比如Vue v-for 或 React map）里，别在循环中拼接内联 onerror 字符串——容易漏掉 this.onerror=null，也难统一管控。
- 用全局捕获代替逐个绑定：
document.addEventListener('error', e => { ... }, true)，加true进入捕获阶段，确保能截获所有 - 给每张图加标记：
data-fallbacked="true"，避免同一张图被多次替换 - 备用图必须是绝对路径或 base64：
data:image/svg+xml;base64,PHN2Zy...，彻底绕过路径解析和二次404风险
服务端配合减少客户端负担
前端兜底只是最后一道防线。真正要优化性能，得让失败尽量不发生：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 构建时检查图片路径是否存在（比如用
html-validate+ 自定义规则） - CDN 配置 404 响应为一个轻量占位图（如 1×1 透明 PNG），状态码仍返回 404，但浏览器不会再次触发
onerror - 服务端渲染（SSR）时，提前校验
src是否可访问，不可用则直接输出 fallback 图的src，跳过客户端逻辑
注意 onload 和 error 的竞态问题
onload 和 onerror 是异步事件，顺序不确定。如果图加载极快（比如本地缓存），onload 先触发，但你的 fallback 逻辑又写了 img.onload = () => { img.classList.remove('loading') }，而 onerror 还没清掉，就可能留下 loading 状态。
- 统一用
Promise.race([load, error])封装单图加载逻辑（适合 JS 控制的懒加载场景） - 或改用
img.decode()+try/catch：它会在解码失败时 reject，比依赖事件更可控 - 永远不要假设
onerror一定会在onload之后执行
真实项目中最容易被忽略的，是备用图本身的加载成本——一张 20KB 的 fallback.jpg 在弱网下也会触发延迟和重试，反而拖慢首屏。用 SVG 占位图或 base64 内联，才是循环列表里真正零开销的 fallback。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
