object标签fallback仅在明确加载失败（404/CORS/type不匹配）时触发，且内部内容必须是合法HTML元素（如<p>、<img>），纯文本、注释、<script>或空格均无效。
object 标签内部的 fallback 内容必须是合法 HTML 元素
浏览器只在明确加载失败（如 404、CORS 拒绝、type 与响应头不匹配）时才渲染 <object> 内部内容。但这个“内部内容”不是随便写的——它必须是有效的 HTML 子节点。
常见错误包括：
- 写纯文本或空格：
<object data="x.pdf">无法加载</object>→ 不触发 fallback - 放注释：
<!-- fallback -->→ 忽略 - 嵌套另一个
<object>→ 大多数浏览器不识别为 fallback，可能递归失败 - 只写
<script>或<style>→ 不算有效降级内容
正确做法是用 <p>、<img>、<a> 等语义化标签包裹提示或替代资源。例如：<p>PDF 加载失败，请<a href="doc.pdf">点击下载</a></p>
嵌套 必须严格位于 object 开始与结束标签之间
<param> 不是可选装饰，而是插件参数的唯一合法载体。它不能写在 <object> 外部，也不能塞进 <body> 顶层；位置错，参数就失效。
立即学习“前端免费学习笔记（深入）”；
关键细节：
-
name值必须完全匹配插件文档要求，比如 Flash 要flashvars，不是FlashVars或flashVars -
value含&、=、中文等字符时，需提前用encodeURIComponent()编码，否则截断 - 多个
<param>顺序通常无关，但 RealPlayer 等老插件要求src参数必须排第一
错误示例：<object data="p.swf"></object><param name="movie" value="p.swf"> → 参数被忽略
object 嵌套 object 是可行的，但仅限 fallback 场景且有兼容限制
规范允许在 <object> 内部再写一个 <object> 作为降级方案，用于适配不同浏览器对同一资源类型的处理差异（比如 Chrome 和 Safari 对 PDF 的支持逻辑不同）。
但要注意：
- 内层
<object>仍受相同规则约束：必须有data或type，且 fallback 内容也得合法 - Firefox 对嵌套
<object>支持较弱，尤其在file://协议下容易静默失败 - 不要为了“多一层保险”而无意义嵌套——现代浏览器对 PDF 的处理已趋一致，嵌套反而增加不可控路径
典型用法是外层尝试 PDF，内层 fallback 到 <iframe src="doc.pdf"> 或下载链接，而非再套一个 <object>。
type 和 data 的组合决定是否触发嵌套逻辑
<object> 是否尝试加载、何时 fallback、是否允许嵌套，全由 type 和 data 的存在性与匹配度决定。
几个硬性条件：
- 只写
type不写data→ 渲染空白区域，不触发任何嵌套或 fallback - 只写
data不写type→ 浏览器按文件扩展名猜测类型，但若服务端响应头Content-Type不匹配（如 PDF 返回text/plain），仍会 fallback - 写了
type="application/pdf"但服务端返回404→ 触发 fallback，此时内部内容才生效 - 加了
typemustmatch属性 → 即使type和响应头轻微不一致（如大小写），也会强制 fallback
真正复杂的点在于：这些判断发生在网络层和 MIME 解析层，开发者看不到中间过程，只能靠响应状态码和控制台 Network 面板确认是否真的“加载失败”。本地开发时用 file:// 协议几乎必然失败，必须走 http://localhost 才能模拟真实环境。
