图片加载失败兜底必须闭环：onerror需用dataset标记防循环，动态img须提前绑定，fallback优先用base64 SVG，路径统一绝对路径，alt与onerror各司其职不可替代。
图片加载失败不是“要不要兜底”的问题，而是“兜底逻辑是否闭环”的问题。只写 onerror 会卡死，只靠 alt 会留白，只换 src 会循环触发错误——真正可用的降级必须同时控制加载行为、标记状态、隔离路径风险。
img 的 onerror 为什么一写就卡死？
因为备用图也 404 时，onerror 会无限重试：新 src 加载失败 → 再触发 onerror → 再换 src……最终内存暴涨或页面无响应。
- 必须用
dataset打标切断链路：onerror="if (!this.dataset.loaded) { this.dataset.loaded = '1'; this.src = '/img/placeholder.svg'; }" - 动态创建的
img元素，onerror必须在appendChild()前绑定，否则首次失败捕获不到 - 备用图优先用内联 base64 SVG（如
data:image/svg+xml;base64,PHN2Zy...），彻底规避路径解析和跨域问题
如何让 fallback 图不被二次拦截？
本地开发时双击打开 HTML，或部署后路径错位，90% 的“加载失败”其实源于 file:// 协议拦截或相对路径解析偏差，不是图片真丢了。
- 所有图片路径统一用绝对路径：
src="/img/logo.png"，而非./img/logo.png或../assets/logo.png - 开发阶段必须用 Live Server（如 VS Code 的 Ritwick Dey 插件），禁用直接双击打开
.html文件 - 服务端返回的占位图（如
/img/missing.png?text=404）需确保 Nginx/Apache 配置了该路径的 fallback 响应，不能依赖前端 JS 补救
alt 和 onerror 是两套独立机制，不能互相替代
alt 解决语义与可访问性，onerror 解决资源加载异常；一个缺失不影响另一个运行，但两者都缺，用户就只剩断裂图标。
立即学习“前端免费学习笔记（深入）”；
-
alt是 HTML5 强制属性，省略会导致构建工具报错（如 ESLintjsx-a11y/alt-text规则） -
alt=""表示“纯装饰”，读屏器跳过；alt省略则可能被读出src路径，造成干扰 - CORS 拦截、MIME 类型不匹配（如 WebP 在旧 Safari）、服务端 406 响应等场景下，
onerror根本不会触发，此时只有alt能提供文字提示
关键图片必须跳过懒加载，且 src 不可为空
首屏商品图、头图、登录按钮图标等，一旦因懒加载降级失败或 JS 加载中断，用户看到的就是空白区域——这不是体验问题，是功能不可用。
- 这些图片直接写死
src，不加loading="lazy"，也不设data-src -
src必须指向真实可访问地址（如/img/hero.jpg），不能是占位图或空值；SSR 渲染时也要确保该路径在服务端可命中 - 若必须用懒加载，
src应为 1px GIF 或 LQIP 模糊图，data-src存高清图地址，且初始化代码必须内联进<script>，避免外部 JS 加载失败导致全量白屏
最易被忽略的是：所有降级方案都假设浏览器至少能执行基础 DOM 操作。如果用户禁用 JS，或网络中断导致内联脚本加载失败，onerror 和 IntersectionObserver 全部失效——这时唯一可靠的 fallback，就是 src 本身指向一个始终可用的资源。
