是html5中的void元素，不可写闭合标签或嵌套内容，必须包含src和alt两个必需属性，width/height仅接受数字或百分比值；其解析非阻塞，图片加载异步进行。
浏览器遇到 <img> 时根本不停顿
解析 HTML 的过程本身不会因为 <img> 标签而暂停。浏览器在标记化（tokenization）阶段一看到 <img src="a.jpg">，就立即创建一个空的 HTMLImageElement 节点加入 DOM 树，同时**异步发起图片请求**，然后继续往下解析后续标签 —— 不等图片下载、不解码、不等渲染。
这意味着：<img> 是典型的「非阻塞解析」标签。你可以在 里放一百个 <img>，HTML 解析器照样一路扫到底。
常见错误现象：
• 页面 DOM 已就绪，但 img.naturalWidth 还是 0
• 在 DOMContentLoaded 回调里直接读取图片尺寸或调用 getBoundingClientRect()，结果值不准
原因不是解析慢，而是图片资源还没加载完成。要等它，得监听 load 事件或用 decode() API。
src、srcset 和 sizes 的加载决策发生在哪一步
浏览器在构建完 DOM 并进入「布局前准备」阶段（即 CSSOM 就绪后、Layout 开始前），才真正决定加载哪张图。这个决策不发生在 HTML 解析时，而是在样式计算之后：
-
src：只要节点插入 DOM，就立刻发起请求（兼容兜底） -
srcset+sizes：先算出图片容器的「渲染宽度」（依赖 CSS 布局结果），再匹配最接近且不小于该宽度的w描述符项 - 如果
sizes缺失或写错（比如硬写sizes="100vw"但实际容器 max-width 是 600px），浏览器会退回到设备像素比（DPR）逻辑，小屏也可能加载大图
注意：<picture></picture> 的 <source></source> 匹配也是在这阶段完成，且按从上到下的顺序逐个判断 media，命中即停；全不匹配才 fallback 到内部 <img> 的 src。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
为什么设 width 和 height 能避免回流
<img> 是可替换元素，有固有尺寸（intrinsic size）。浏览器在解析 HTML 时，如果看到 width 和 height 属性（无论带单位与否），就会立即为该元素预留对应空间，DOM 构建完、CSS 计算完后，布局引擎能直接复用这个占位尺寸。
没设宽高时的问题：
- 初始布局把图片当 0×0 处理，文字/其他元素按此排布
- 图片加载完成后，真实尺寸出现，触发 layout → reflow → paint 链路重跑
- 在瀑布流、图文混排或 SSR 页面中，这种“内容跳动”尤其明显
现代写法推荐只设一个维度（如 width="320"），让 height 自动等比缩放；或者用 CSS 的 aspect-ratio + width: 100% 更灵活控制。
懒加载 loading="lazy" 实际延迟了什么
loading="lazy" 延迟的是「图片请求发起时间」，不是解析，也不是 DOM 插入。它只对离屏图片生效（当前视口外约 1250px 范围内会预加载），规则由浏览器内置策略控制。
关键事实：
- 即使加了
loading="lazy"，<img>节点仍会在 HTML 解析时同步创建并加入 DOM - 该属性不影响
DOMContentLoaded触发时机，也不影响 JS 对该元素的访问 - 滚动靠近时，浏览器才真正调用
fetch()发起请求；此时若网络慢，依然可能触发load或error事件 - 服务端无法感知这个 lazy 行为 —— 它只是客户端的加载调度策略
容易被忽略的一点：如果你用 JS 动态设置 img.src，loading="lazy" 会失效，必须在元素首次插入 DOM 前就存在该属性。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
