onerror循环导致页面卡死或内存飙升，表现为滚动卡顿、DevTools响应迟缓、标签页无响应；虽控制台仅显示一次404，但Network面板可见多次同名fallback请求，performance.memory.usedJSHeapSize持续上涨可验证。
onerror触发后页面卡死或内存飙升就是循环了
不用查日志、不用加 debugger，最直接的判断是：图片加载失败后，页面明显变卡、滚动卡顿、DevTools 响应迟缓，甚至标签页无响应——这基本就是 onerror 在反复重试。浏览器不会报错提示“你写循环了”，但会静默进入高频重加载状态，CPU 和内存占用会肉眼可见地拉高。
为什么 console 看不到重复错误信息
onerror 事件本身不冒泡，且现代浏览器对连续失败有降级抑制机制：第二次起可能不再触发事件监听，也不往控制台打印新错误（尤其 Safari 和 Chrome 新版本）。所以你只看到一次 404，不代表只加载了一次——它可能已默默重试了 5–10 次。
- 打开 DevTools → Network 面板，过滤
img，观察是否出现多个同名 fallback 请求（比如/fallback.png被发了 3 次） - 在 Performance 面板录一段加载过程，看是否有密集的
Image.decode或Resource loading任务堆积 - 用
performance.memory在控制台手动查：连续执行几次performance.memory.usedJSHeapSize，数值持续上涨就高度可疑
怎么用 JS 主动验证 onerror 是否被切断
在页面加载完成后，快速检查所有 <img alt="HTML怎么检测图片onerror是否陷入循环" > 元素的 onerror 属性值是否还包含函数逻辑：
document.querySelectorAll('img').forEach(img => {
const attr = img.getAttribute('onerror');
if (attr && attr.includes('this.src') && !attr.includes('this.onerror=null')) {
console.warn('⚠️ 检测到潜在循环风险:', img.src, 'onerror=', attr);
}
});
注意：img.onerror 属性（JS 属性）和 onerror HTML 属性是两个东西。上面检查的是内联属性，这是唯一可靠的检测入口；动态绑定的 img.onerror = ... 无法通过 DOM 属性读取，且本就不推荐。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
真正防住循环的关键不是“写没写 null”，而是 fallback 图本身必须可达
很多团队写了 this.onerror=null 还出问题，是因为 fallback 路径仍是相对路径、拼错大小写、或依赖未上线的 CDN。最终效果是：第一次 src 失败 → 触发 onerror → 换成 /assets/fallback.svg → 该路径返回 404 → 浏览器直接丢弃后续 onerror（不报错也不重试），但图片仍为空白，用户以为“降级成功了”，其实根本没加载出来。
- fallback 必须用绝对路径（如
/static/placeholder.svg）或 base64（如data:image/svg+xml;base64,PHN2Zy...） - 部署前用 curl 或浏览器地址栏直访 fallback URL，确认 HTTP 状态码是 200 且 Content-Type 正确
- 避免在 fallback 路径里带查询参数（
?v=1.2）、hash（#icon）或变量插值（${env}/fallback.png），这些都可能在 SSR 或构建阶段出错
循环只是表象，根源永远是资源路径不可靠——别把防御逻辑建在沙子上。
