embed标签在2026年已无真正文档结构定义——W3C/WHATWG将其标记为遗留特性，不定义内容模型、不支持子元素、无语义化文档流、无fallback、无aria透传，仅依赖src（HTTP/S）、type（仅application/pdf有效）、宽高（必须具体像素值）三要素做粗粒度渲染。
embed 标签在 2026 年已不是“可深入剖析的结构”，而是被浏览器实际废弃的遗留接口——它没有标准化的文档结构定义，只有历史残留的属性表和失效行为。
为什么 embed 没有真正意义上的文档结构定义
HTML 规范中从未为 embed 定义内容模型（content model），即它不接受子元素，也不参与语义化文档流。它本质是一个“空标签容器”，浏览器只按 src + type + 尺寸做粗粒度渲染，不校验嵌套、不触发 DOM 事件冒泡、不支持 aria-* 属性透传。W3C 和 WHATWG 都将其标记为“遗留特性”，不纳入现代语义化树构建逻辑。
常见误解是把它当 object 或 iframe 看待，但 embed 不支持 fallback 内容，无法设置 role，也没有 contentDocument 接口。它的 DOM 节点始终是孤立的 HTMLUnknownElement 实例（Chrome/Firefox 中表现为 HTMLEmbedElement，但行为无实质差异）。
embed 的实际解析规则：浏览器只看这三件事
现代浏览器对 embed 的处理极其简化，仅依赖以下三项做最小决策：
立即学习“前端免费学习笔记（深入）”；
-
src必须为有效 HTTP(S) URL；file://协议直接拒绝加载（控制台报net::ERR_ACCESS_DENIED） -
type仅用于 PDF 场景：必须严格等于application/pdf，其他值（如video/mp4）被忽略，不触发 MIME 类型协商 -
width和height必须为具体像素值（如width="800"），百分比、auto、100%全部导致渲染区域塌陷为 0×0
检查 embed 是否真在工作？别信视觉，看 Network 和响应头
很多开发者以为页面显示空白就是代码写错了，其实更可能是后端没配对 PDF 响应头。验证方式只有两个硬指标：
- 打开开发者工具 → Network 标签页 → 找到对应 PDF 请求 → 状态码必须是
200 - 响应头中必须包含
Content-Type: application/pdf，且不能有X-Content-Type-Options: nosniff干扰 - 若满足以上两点仍空白，说明用户设备未启用 PDF 查看器（如 Chrome 的内置 PDF Viewer 被禁用，或系统级 PDF 关联失效）
真正需要结构定义的内容，应该用 iframe（HTML 页面）、video（视频）、img（图片）或 object（需 fallback 的复杂资源）。embed 现在只剩一个作用：给旧系统留个兼容占位符，别指望它承载任何可靠结构。
