onerror必须在createElement后、appendChild前绑定，否则因加载过快而失效；fallback需配this.onerror=null防死循环；全局error监听须用捕获模式并严格过滤；重试需唯一data-retry-key标识并更新URL参数防缓存。
瀑布流中动态插入的![HTML怎么在瀑布流循环加载时捕获onerror]()
为什么onerror总不生效
因为图片插入 DOM 后立刻开始加载，等你用 appendChild() 再绑 onerror，错误已经发生、事件监听器根本没机会注册。这不是代码漏写，而是时序错位——浏览器根本不给你“事后补救”的机会。
- 必须在
document.createElement('img')之后、appendChild()之前就绑定onerror - 不能用字符串拼接内联属性（比如
innerHTML += '<img src="https://img.php.cn/" alt="HTML怎么在瀑布流循环加载时捕获onerror">'），解析阶段无法保证执行顺序 - 若用模板字符串或框架渲染，确保
onerror是 JS 属性赋值，而非 HTML 字符串插值
怎么写才能防止瀑布流里onerror触发死循环
瀑布流常批量加载图片，一旦 fallback 图也 404，所有图片同时进入无限降级，内存飙升、页面卡死是常态。核心不是“限制次数”，而是“切断链路”——只要备用图路径不可达，this.onerror=null 就是保命线。
- 绝对禁止只写
this.src = '/fallback.svg'，必须紧跟this.onerror = null，且用分号隔开 - 推荐直接用 base64 内联 SVG：
this.src = 'data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAi...'; this.onerror = null;，彻底规避路径解析失败 - 如果 fallback 要走 CDN，务必提前验证该 URL 在当前环境（本地开发 / file:// / CDN 域名）下真实返回 200
全局监听 error 事件在瀑布流里靠不靠谱
对大量动态插入的图片，逐个绑定 onerror 成本高、易遗漏。全局监听看似省事，但默认不捕获图片错误——error 事件不冒泡，必须用捕获阶段才能命中。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 监听必须带第三个参数
true：document.addEventListener('error', handler, true) - 要加
dataset标记防重复处理：e.target.dataset.handled = '1'，避免同一张图被多次替换 - 过滤条件必须严格：
e.target.tagName === 'IMG' && !e.target.dataset.handled，否则 script、link 错误也会进来 - Safari 旧版对捕获阶段支持不稳定，生产环境建议 fallback 到元素级绑定
瀑布流重试按钮怎么精准关联某张失败的图
用户点击“重试”，你得知道是哪张图、哪个 URL、甚至哪个瀑布流区块里的图要重载。靠 class 名、索引或父容器位置匹配，DOM 一变就失效。
立即学习“前端免费学习笔记（深入）”；
- 每张图插入前必须带唯一标识：
img.dataset.retryKey = 'feed-item-123-avatar' - 按钮也要同步该 key：
<button data-retry-key="feed-item-123-avatar">重试</button> - 点击时用
document.querySelector('[data-retry-key="' + key + '"]')精准定位，不依赖层级 - 重试前先清空
src：img.src = ''，再赋新值，否则浏览器可能跳过请求（尤其缓存了 404 响应）
?v=123 或 &t=1730055600），重试时若没更新时间戳或版本号，浏览器很可能直接返回缓存的 404 响应——看着点了重试，其实什么都没发出去。 
