最常见隐患是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 或确认该路径已在所有环境部署并可访问。
排查动态插入的 img 是否漏绑或时序错误
静态 HTML 的 onerror 容易查，但 JS 动态创建的 <img alt="HTML代码审查如何发现onerror循环隐患" > 更容易出问题。典型错误是：
- 先设
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 -
<picture></picture>中只有<source></source>，而内部<img alt="HTML代码审查如何发现onerror循环隐患" >的src是无效地址 —— 错误落在<img alt="HTML代码审查如何发现onerror循环隐患" >上，但开发者常误以为<picture></picture>会接管兜底
真正要盯住的，永远不是“有没有写 onerror”，而是“这个 src 在目标环境（CDN / 本地 / file://）下是否真实可访问、是否返回 200 + 图像数据”。
