Stack overflow at line: 0 是 onerror 无限循环的典型现象，主因是备用图路径无效或 CORS 拦截导致反复触发错误处理；解决需清除 onerror、用 base64 占位图或显式设置 crossorigin 属性。

onerror 无限循环的典型错误现象

页面卡死、标签页无响应、控制台报 Stack overflow at line: 0，或内存占用飙升——这基本就是 onerror 循环触发的明确信号。它不是偶然发生，而是备用图（fallback）本身也加载失败后，浏览器再次进入同一段 onerror 处理逻辑，形成死递归。

如何快速判断是路径问题还是 CORS 问题

打开开发者工具的 Network 面板，刷新页面，观察两个请求：

• 原始 的状态码：如果是 404 或 0（连接中断），说明网络层失败，onerror 合理触发；
• 备用图（如 this.src='/assets/placeholder.svg'）的请求状态：如果也返回 404 或 0，就是路径错误，直接导致循环；
• 如果原始图请求显示 Blocked by CORS policy，但状态码是 200，说明图片其实下载成功了，只是被浏览器策略限制读取尺寸——这时 onerror 仍会触发（这是浏览器行为），但换源无效，必须改用 crossorigin 属性或服务端代理。

为什么 crossOrigin 属性不能省略

跨域图片即使能显示，也可能因缺少 crossorigin 导致后续判断失灵：

Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转

实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。

下载

• img.naturalWidth 在未设 crossorigin 时恒为 0，无法区分“加载失败”和“CORS 拦截”；
• 你写的 onerror 逻辑可能依赖 naturalWidth 做二次校验，结果误判；
• 正确写法必须显式带上属性：，值可为空（crossorigin）或 anonymous；
• 若 CDN 不支持 CORS 响应头，加了 crossorigin 反而会让原本能显示的图变空白——此时只能换源或走代理。

真正安全的 fallback 方案长什么样

不依赖外部路径、不触发额外网络请求、不被 CORS 干扰：

• 用内联 SVG base64 占位图：data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMzAiIGhlaWdodD0iMzAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+PHJlY3Qgd2lkdGg9IjEwMCUiIGhlaWdodD0iMTAwJSIgZmlsbD0iI2ZmZiIvPjwvc3ZnPg==；
• onerror 必须带 this.onerror=null，否则哪怕 fallback 是 base64，某些旧版浏览器仍可能因解析异常再进一次 error；
• 动态插入的 ，事件绑定必须在 appendChild() 之前完成，否则首次错误已发生，监听器永远收不到；
• 服务端渲染首屏图片时，src 应直接输出可用占位图 URL，不要留空或拼错相对路径（如 ./missing.jpg）。

最常被忽略的一点：onerror 只管“请求发出后失败”，对空 src、CORS 阻塞、服务器返回 200 的兜底 HTML 页面完全不响应——你以为它在兜底，其实它根本没启动。

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