onerror 循环必须服务端参与，因浏览器 onerror 仅响应真实网络错误或状态码≥400的响应，若服务端将404伪装为200（如Nginx用error_page 404 =200 /fallback.html），onerror完全不触发；服务端须确保失败路径返回真实404等错误状态，并对fallback资源做路径校验、限流及独立域名隔离。
onerror 循环为什么必须在服务端参与拦截
浏览器端 onerror 只能响应“请求发出后失败”，但无法区分是资源真丢了，还是服务端返回了伪装成功的兜底页（比如 Nginx 配置了 try_files @fallback，404 时返回 200 状态码的 HTML 页面）。这种情况下，onerror 根本不触发——你写的降级逻辑彻底失效。服务端必须提前介入，确保失败路径真实返回 404 或其他可被浏览器识别的错误状态。
服务端如何让 onerror 正常触发而非静默失败
常见错误是后端对图片路径做了无差别 fallback：所有 /img/*.png 请求都代理到 CDN，CDN 不命中就返回一个带文字的 200 占位图。这会让浏览器认为“加载成功”，onerror 永远不会执行。
- 图片静态资源路径必须由独立 location 块处理，禁用
try_files或error_page自动兜底 - Nginx 示例：
location ^~ /img/ { add_header Access-Control-Allow-Origin "*"; expires 1y; }—— 不加try_files，让 404 真正透出 - 若需兜底，应在 404 响应体中返回纯二进制占位图（如 1×1 PNG），且 HTTP 状态码必须为
404，不能是200 - 开发环境用
file://协议时，服务端逻辑不生效，必须搭配 Live Server 启动，否则所有相对路径解析都会错位
服务端配合前端防循环的关键动作
前端靠 this.onerror = null 切断单次循环，但服务端要防止「多端共用同一张 fallback 图却集体 404」——比如把 /img/fallback.svg 部署漏了，所有页面都卡死。
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 所有 fallback 路径必须走绝对路径，且由服务端统一托管，例如
/static/fallback.svg，禁止用./fallback.svg或../assets/fallback.svg - 构建流程中加入校验：CI 脚本检查
src和onerror中出现的所有 fallback 路径是否真实存在于 dist 目录 - CDN 配置 fallback 图时，必须启用健康检查，一旦源站该路径不可用，立即切回源站直连，避免 CDN 缓存住 404 响应
- 若 fallback 图本身也需降级（极少见），服务端应返回 base64 内联 SVG，彻底绕过路径解析环节
为什么只靠前端 this.onerror=null 还不够
它只解决“单个标签内重复触发”，但挡不住并发请求下的全局雪崩。比如 20 张图同时失败，每张都换到同一个备用地址，瞬间打爆该 URL 的 QPS，导致备用图也 404，全部二次触发 onerror。
立即学习“前端免费学习笔记（深入）”；
- 服务端应对 fallback 路径做限流（如 Nginx 的
limit_req），单位时间只允许少量请求通过 - 更稳妥的是让 fallback 图走独立域名（如
https://static.example.com/fallback.svg），与主资源域名隔离，避免 DNS 或连接池故障传导 - 首屏关键图的服务端响应必须带
Cache-Control: immutable，防止浏览器反复重试已知失败的地址
this.onerror=null 就完事——服务端得确保那个 null 之后指向的地址，本身不会成为下一个失败点。 
