figure/figcaption 必须用于可独立引用的自包含内容单元，如学术图表、代码示例；判断标准是能否抽离正文而不影响主文理解，且 figcaption 应置于 figure 首位以保障可访问性。
figure 和 figcaption 不是用来“给图片加个居中文字”的样式工具，而是告诉浏览器、搜索引擎和读屏软件：“这一块内容是自包含的、可独立引用的单元，这段文字就是它的官方说明”。
什么时候必须用 figure/figcaption，而不是 div + img + p？
核心判断标准只有一条：这个图（或代码块、图表、引用等）能否从正文中抽出来，单独放在附录、侧栏或参考文献里，而不影响主文理解？
- 学术论文里的“图3.2：系统架构图”——必须用
figure，否则编号、交叉引用、辅助技术识别都会失效 - API 文档中一段
<pre class="brush:php;toolbar:false;"><code>{ "status": "ok" }</code></pre>加说明“响应示例”——适合figure包裹，figcaption标注用途 - 文章段落中解释某句话的配图（如“如图所示，点击按钮后状态变化”）——直接用
<img alt="...">更合适，figure反而语义过载 - 轮播图、头像、banner 图、纯装饰性 icon——一律不用
figure，它们不属于“可被引用的独立内容单元”
figcaption 必须放在 figure 的开头还是结尾？
HTML 规范没强制位置，但 DOM 顺序直接影响可访问性。屏幕阅读器按 HTML 流顺序读取，先读 figcaption 再读图，用户才能带着上下文理解图像；若写在后面，会先听到“一张图”，再听到“这是系统流程图”，认知断层明显。
- 推荐始终把
figcaption放在figure的第一个子元素位置 - 不要用
flex-direction: column-reverse或orderCSS 属性去“视觉上倒序”，这会破坏语义流 - 浏览器默认渲染时，无论
figcaption写在前还是后，通常都显示在底部；但语义和读屏逻辑只认 DOM 顺序
常见错误写法与兼容性注意点
这些错误不会让页面“不显示”，但会让语义失效、SEO 减分、读屏器误读：
- 在一个
figure里塞两个figcaption—— 违反规范，第二个会被忽略或导致解析异常 - 把说明文字包在
<div><p>...</p></div>里再放进figure—— 辅助技术无法识别这是“图的标题”，只能当普通段落 - 用
figure包含带操作按钮的图（如“截图+下载按钮”）——figure只管图与说明这对语义单元；按钮应放在figure外，用<div class="figure-wrapper"> 统一包裹 <li>IE 8 及更早版本不支持 <code>figcaption—— 若需兼容，得降级为<p class="fig-caption"></p>并手动关联aria-labelledby，但 2026 年绝大多数项目已无需考虑 -
alt是图像缺失时的简短替代，比如alt="蓝色折线图，显示2025年Q1-Q4用户增长" -
figcaption提供完整语境，比如<figcaption>图 4.1：2025 年各季度 DAU 增长趋势（数据来源：内部 BI 系统）</figcaption> - 如果图本身信息密度高（如复杂图表），
alt应精炼概括，细节交由figcaption补充；反之，若图很直观（如产品照片），figcaption可侧重用途或来源
figcaption 和 img 的 alt 属性怎么分工？
两者不是替代关系，是协作关系：一个描述“图是什么”，一个说明“图为什么在这儿”。
最容易被忽略的是：figcaption 的内容必须“自包含”。哪怕把它剪下来贴到邮件里，收件人也该看懂它在说什么——不能依赖前后文中的代词、缩写或未定义术语。
