图片加载失败无自动降级，需分层应对：onerror须用data-loaded防死循环，备用图优先base64内联；中为强制兜底；必须设宽高防塌陷；file://协议下90%失败实为浏览器拦截。
图片加载失败时，浏览器不会自动换图、不报错、也不触发重试——它就留白或显示 alt 文本。降级不是“加个备用地址”就能解决，而是要同时控制 HTML 结构、事件链、资源路径和 CSS 占位。
onerror 必须带 data-loaded 标记防死循环
只写 onerror="this.src='fallback.png'" 是危险操作：如果 fallback.png 也 404，会再次触发 onerror，无限递归导致内存飙升甚至页面卡死。
- 正确写法：
onerror="if (!this.dataset.loaded) { this.dataset.loaded = '1'; this.src = 'data:image/png;base64,iVBOR...'; }" - 动态创建的
<img>元素，onerror绑定必须在appendChild()之前完成，否则首次错误捕获不到 - 备用图强烈建议用 base64 内联，彻底避开路径解析失败、跨域、file:// 协议拦截等问题
的 ![]()
是强制兜底，不是可选项
<picture></picture> 中所有 <source></source> 都失败时，浏览器仍会尝试加载内部 <img>；但如果它的 src 也是 404 或空值，最终只显示 alt 文本，整个区域塌陷。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
<img src>必须指向一个静态可直访的真实资源（如 CDN 上的占位图），不能是相对路径./missing.jpg，更不能带查询参数如logo.jpg?format=webp - 服务器返回 404 时，可配置 Nginx 返回带文字的占位图（如
/img/missing.png?text=404+logo），比纯白更友好 - 不要把 JPEG/PNG 写成第三个
<source></source>——它不会被当作 fallback，只有<img>的src才是最后一道防线
断网或 JS 失败时，HTML 层必须自洽
懒加载、动态注入、JS 校验这些都依赖网络和执行环境。一旦 JS 加载失败（比如拦截器、弱网、file:// 协议），整套逻辑就归零——但用户看到的不该是满屏空白。
- 首屏关键图（如 logo、主图）跳过懒加载，直接写死
src，不设data-src，不加loading="lazy" - 所有图片必须写
width和height（或用 CSSaspect-ratio），避免加载失败后布局抖动 - 全局监听
window.addEventListener('error', e => { if (!(e instanceof ErrorEvent) && e.target?.src) { /* 上报或记录 */ } }, true)，捕获未显式处理的资源失败
file:// 协议下 90% 的“加载失败”其实是浏览器拦截
双击打开 HTML 文件时，file:// 协议会封锁所有以 / 开头的路径请求（比如 /css/app.css 被解析成系统根目录），控制台显示 net::ERR_FILE_NOT_FOUND ——这不是代码写错了，是协议限制。
- 本地开发务必用
http-server、live-server或 VS Code Live Server 插件启动本地 HTTP 服务 - 绝对路径要改写为相对于当前 HTML 的路径（如
./assets/logo.png），或统一用 base64 - 服务端渲染（SSR）场景下，
src值应在生成 HTML 时就确认可用，不能寄希望于客户端 JS 补充
真正难的不是写几行 onerror，而是在 JS 不可用、网络中断、协议受限、CSS 干扰等多重边界条件下，让 DOM 自身仍能呈现合理内容。每个 <img> 都得是“独立可运行单元”，而不是依赖外部条件的半成品。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
