figure标签用于封装可抽离、可编号、可独立理解的语义单元，视频天然满足可抽离性故更常用；音频需谨慎判断独立性，figcaption须结构化说明内容而非泛称；音视频均不支持alt，figcaption承担全部语义说明职责。
figure 包裹视频更常见且语义更稳固
视频通常自带时间轴、视觉叙事和上下文完整性，天然满足「可抽离性」要求：
- 删除视频后，正文仍能靠文字描述讲清逻辑（如“系统通过 WebSocket 实时推送状态变更”）
- figcaption 可明确标注时间范围、场景角色或技术要点（例：“图6：用户登录后3秒内完成 token 刷新的 WebSocket 通信抓包”）
- 浏览器和读屏器普遍将
<video>视为高信息密度媒体，figcaption 的语义绑定效果强
建议写法：
- 必须包含
controls属性，确保基础可操作性 -
<source>或直接src需明确格式，避免 fallback 失效 - 若含字幕，
<track>应作为<video>子元素，不放入 figcaption
figure 包裹音频需更谨慎判断是否真“独立”
纯音频缺乏视觉锚点，用户难以仅凭 figcaption 理解其内容全貌，容易导致语义弱化：
- 一段 API 调试用的 HTTP 请求响应音频，若正文未说明“听此音频可分辨 401 与 403 响应的语音提示差异”，则音频就不是独立单元
- figcaption 写成“图7：错误响应语音提示”不够，必须补充可操作信息（如“男声提示‘权限不足’，持续1.8秒，采样率16kHz”）
常见误区：
- 把背景音乐、页面加载音效塞进
<figure>——它们是装饰性或功能性元素，不构成可引用图元 - 用
<audio>替代文字说明，指望用户靠听觉补全技术细节——违背无障碍前提
figcaption 与 alt 的分工在音视频中同样不可互换
-
<video>和<audio>本身不支持alt属性，但其内部<source>无替代文本能力，所以 figcaption 承担全部说明职责 - 若视频/音频含关键视觉信息（如录屏中弹窗位置、波形图峰值），应在 figcaption 中结构化描述，或额外提供文字稿作为降级内容
- 示例合规写法：
<figure> <video controls width="640" height="360"> <source src="debug-flow.webm" type="video/webm"> <p>您的浏览器不支持 video 标签，请下载<a href="debug-flow.mp4">MP4 版本</a>。</p> </video> <figcaption>图8：前端拦截 401 响应并触发 refresh_token 流程的完整录屏（0:12–0:47，含控制台日志与网络面板同步显示）</figcaption> </figure>
音视频以外的同类语义容器也适用相同原则
-
<code>块配说明文字时可用<figure>，如调试命令输出截图或终端日志片段 - SVG 图表、数学公式、甚至
<blockquote>引用技术文档原文，只要满足「删掉它正文仍自洽 + 有编号说明需求」，就适合套<figure>
本质上，figure 不区分媒体类型，只认一个标准：它包裹的内容是不是一个可被引用、可被移走、可被单独理解的语义单元。
