图片服务器异常时应采用多源url+同源静态fallback方案：主备域名通过环境变量注入，关键图服务端直出fallback，优先使用base64内联占位图，辅以同源静态资源，并由nginx或网关层拦截错误返回本地兜底。
图片服务器异常时，用户看到的不是“加载中”，而是白屏、灰块或 alt 文本——这不是前端没写好 onerror，而是整个资源路径已不可达，且降级逻辑未覆盖服务端故障场景。核心对策是：让图片请求不依赖单一服务器，同时确保 fallback 路径完全静态、可直访、零外部依赖。
图片 URL 必须支持多源切换，不能硬编码单个域名
把所有 src 或 srcset 写成 https://img.example.com/xxx.jpg 是高危操作。一旦该域名 DNS 失败、CDN 回源中断或证书过期，整页图片即失效。
- 用环境变量或构建时注入主备域名，例如：
https://img1.example.com/xxx.jpg（主）和https://img2.example.com/xxx.jpg（备） - 客户端 JS 不应动态拼接完整 URL；应在 HTML 中预置两套地址，通过
data-src-primary和data-src-backup分开存储 - 避免在 CSS
background-image中写死图片地址——它无法监听加载失败，也无法触发onerror
onerror 不能只换一次 src，要防重复触发和跨域静默失败
onerror 在图片 404 时会触发，但遇到 CORS 错误、DNS 拒绝或 TLS 握手失败时，浏览器可能静默失败（不触发事件），尤其在 Safari 和部分 Android WebView 中。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 不要写
onerror="this.src='backup.jpg'"—— 若 backup.jpg 也失败，会无限循环触发 - 加标记位控制仅降级一次：
onerror="if (!this.dataset.fallback) { this.dataset.fallback = '1'; this.src = '/fallback.png'; }" - 对关键图片（如商品主图），服务端渲染时就直接输出 fallback 地址，跳过客户端 JS 降级环节
静态 fallback 图必须内联或托管在主站同源下
把 fallback 图放在另一个 CDN 或 OSS 上，等于把单点故障从图片服务器转移到了另一个服务器——违背降级初衷。
- 最稳方案：使用极简 base64 占位图，如
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8/5+hHgAHggJ/PchI7wAAAABJRU5ErkJggg==，无网络依赖 - 次选方案：将 fallback 图上传至主站静态目录（如
/static/img/fallback.jpg），确保和 HTML 同源、同协议、无需额外鉴权 - 禁用带查询参数的 fallback 地址，如
/fallback.jpg?v=2—— 某些老旧代理会缓存 404 响应，导致永久 fallback
服务端需主动拦截图片 4xx/5xx 并返回兜底响应头
仅靠前端处理是被动防御。若图片服务器已宕机，所有请求都会卡在 TCP 层或返回 503，此时 onerror 根本不会触发。
- Nginx 可配置
proxy_intercept_errors on+error_page 404 500 502 503 /fallback.png，直接由反向代理返回本地 fallback - 主站网关层（如 Spring Cloud Gateway）应对图片路径做路由熔断，超时或失败时自动重写响应为内联 SVG 或 base64
- 禁止用 HTTP 302 跳转到 fallback 图——弱网下跳转链路更长，且可能被拦截
最容易被忽略的一点：图片服务器异常往往伴随 DNS 或 TLS 故障，此时连 onerror 的执行环境都不可靠。真正可用的降级，必须在 HTML 渲染完成前就确定 fallback 资源的可访问性——要么内联，要么同源静态，其余都是幻觉。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
