最常见隐患是onerror内联写法未设this.onerror=null，导致404后无限循环；需确保备用图路径绝对可靠（/开头、完整URL或base64 SVG）；动态创建img须先绑onerror再赋src；空src、CORS阻塞、200伪装404等场景onerror实际不触发。

检查 onerror 内联写法是否缺少 this.onerror=null

这是最常见、最危险的隐患：只要看到 onerror="this.src='...'" 这种写法，没接 this.onerror=null，基本可以判定存在死循环风险。浏览器不会自动终止事件链，一旦备用图也 404，就会无限触发——页面卡死、内存飙升，但控制台往往不报错。

重点盯这些变体：

• onerror="handleFallback(this)" —— 函数里没写 this.onerror = null 就等于没切断
• onerror="this.onerror=null; this.src='...'" —— null 写在赋值前，无效
• onerror="this.src='fallback.png'; onerror=null" —— 漏了 this.，只是声明局部变量

验证备用图路径是否绝对可靠

很多审查者只看语法，却忽略路径本身是否真能加载成功。相对路径（如 ./img/placeholder.png）、未部署的 CDN 地址、或拼错的 /assets/ 前缀，在本地开发可能正常，上线后立刻变成二次 404，触发循环。

安全路径必须满足以下任一条件：

• 以 / 开头的绝对路径（如 /img/placeholder.svg）
• 完整协议 + 域名的 URL（如 https://cdn.example.com/placeholder.svg）
• 内联 base64 SVG（如 data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAi...），这是唯一 100% 可靠的 fallback 方式

遇到 onerror 里用了 PNG/JPEG 路径，直接标记为高风险项，要求替换为 SVG base64 或确认该路径已在所有环境部署并可访问。

使用华数设计生成高保真HTML原型、演示文稿、动画和设计评审

使用经过文档化的设计技能，从真实的品牌或项目背景中生成HTML原生原型、幻灯片、动态演示、可视化图表和评审流程。

下载

排查动态插入的 img 是否漏绑或时序错误

静态 HTML 的 onerror 容易查，但 JS 动态创建的 更容易出问题。典型错误是：

• 先设 img.src = url，再 appendChild()，最后才绑 img.onerror —— 首次加载失败早已发生，监听器根本来不及注册
• 用匿名函数绑定：img.addEventListener('error', () => { ... })，后续无法移除，复用 DOM 时重复触发
• 没加 data-handled 或类似标记，框架 re-render 后再次执行降级逻辑

审查时重点看 JS 创建图片的代码块：onerror 绑定是否在 img.src 赋值之前？是否使用 dataset 标记已处理？是否在替换后显式清除监听器或设 img.onerror = null？

识别 onerror 根本不会触发的“假兜底”场景

有些代码看似写了 onerror，实则完全无效，审查时需主动排除这些情况：

• src 是空字符串、undefined 或纯空格 —— 浏览器根本不发请求，onerror 永远不触发
• 外链图片未加 crossorigin 属性，被 CORS 阻塞 —— 控制台报错，但 onerror 不回调
• 服务器对 404 返回了 200 状态码的兜底 HTML 页面（比如 Nginx 的 404.html）—— 浏览器认为“加载成功”，跳过 onerror
• 中只有 ，而内部 的 src 是无效地址 —— 错误落在 上，但开发者常误以为 会接管兜底

真正要盯住的，永远不是“有没有写 onerror”，而是“这个 src 在目标环境（CDN / 本地 / file://）下是否真实可访问、是否返回 200 + 图像数据”。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！