onerror循环源于Markdown中混入未清理的内联HTML事件，解析器默认保留导致XSS或死循环；需在DOM构建后立即用querySelectorAll精准定位并removeAttribute('onerror')，服务端应配置ALLOWED_ATTR显式剔除。
Markdown 转 HTML 后，onerror 循环不是“转出的 bug”，而是原始 Markdown 里混入了不安全的 HTML 片段（比如手动写的 <img src="x" onerror="alert(1)">），被解析器原样保留并插入 DOM —— 浏览器一渲染就执行，甚至可能触发无限循环或 XSS。
为什么转完 HTML 突然出现 onerror 循环
常见于两类场景：
- 用户在 Markdown 中直接写 HTML 标签，并嵌入了未清理的
onerror属性（例如用于调试或误信“前端降级”教程） - 某些 Markdown 解析库（如 marked、turndown）默认不剥离内联事件处理器，
onerror、onclick等被原样输出 - 服务端渲染时未做 HTML sanitizer，导致恶意或失控的
onerror="this.src='x';this.onerror=null"被注入，但 fallback 图又不可用，形成死循环
如何在转换后安全清理 onerror 属性
不能靠正则全局替换（易漏/误杀），必须在 DOM 构建后、渲染前处理。关键点是：只清理真实存在的 <img> 元素上的 onerror，不碰其他属性，也不动 <link> 或 <script> 的同名属性。
pdf文档转markdown
下载
将PDF文件（含扫描件、图片）转换为Markdown格式。接入MinerU和PaddleOCR双引擎，支持扫描件OCR识别、公式表格解析、多语言识别。兼容本地OCR识别。
- 用
document.querySelectorAll('img[onerror]')精准定位，避免误删data-onerror这类自定义属性 - 对每个匹配元素执行
el.removeAttribute('onerror')，而不是设为空字符串（el.onerror = null在部分旧浏览器中不生效） - 若需保留降级能力，应在转换前统一注入安全 fallback 逻辑（如通过自定义 renderer 注入
data-src+ JS 统一绑定），而非依赖内联onerror - 服务端转换（如用 marked + DOMPurify）应配置
ALLOWED_ATTR: ['src', 'alt', 'class', 'loading']，显式剔除onerror
动态插入内容时 onerror 残留怎么防
Markdown 渲染结果常通过 innerHTML 插入，此时内联事件已注册，removeAttribute 必须在插入后立即执行，否则首帧就可能触发。
立即学习“前端免费学习笔记（深入）”；
- 不要等
DOMContentLoaded：插入后立刻遍历新节点，例如container.innerHTML = html; container.querySelectorAll('img[onerror]').forEach(el => el.removeAttribute('onerror')) - 避免用
insertAdjacentHTML直接插入含onerror的字符串；改用createRange().createContextualFragment()配合遍历清理 - 如果使用 React/Vue，确保 Markdown 渲染组件封装了 sanitizer（如
dangerouslySetInnerHTML前过一遍 DOMPurify），而不是把原始 HTML 当作可信输入 - 本地开发用
file://协议时，90% 的“onerror触发”其实是路径解析失败，清理后反而更早暴露真实问题
真正难清理的从来不是属性本身，而是那些被 onerror 驱动的副作用：修改全局状态、重复 fetch、污染 dataset。清理动作必须在任何业务 JS 执行前完成，且不能依赖外部加载的脚本 —— 它得是页面最顶部那段内联 <script> 里的第一件事。
