object加载PDF时data和type必须严格匹配：data指向资源响应头需为Content-Type: application/pdf，type必须为"application/pdf"，否则静默失败且fallback不触发。
object加载PDF时data和type必须严格匹配
浏览器对 object 加载 PDF 的校验非常苛刻：只要 data 指向的资源响应头不是 Content-Type: application/pdf，或者 type 写成 "pdf"、"text/pdf" 甚至留空，就会静默失败——既不渲染，也不触发 fallback。本地开发用 file:// 协议时，Firefox 可能只认文件后缀，Chrome 则完全依赖响应头，所以务必启动 HTTP 服务（如 npx http-server）预览。
常见错误现象：
-
data="report.pdf"实际路径是/static/docs/report.pdf→ 白屏，不报错，fallback 不显示 -
type="application/x-pdf"→ Chrome 直接跳过内嵌逻辑，可能触发下载 - 服务器返回
Content-Type: text/plain（比如 Nginx 默认配置）→ 页面留空，控制台无提示
实操建议：
- 确保服务端对
.pdf文件返回准确的Content-Type: application/pdf -
type必须写为"application/pdf"，不能缩写 - 加
typemustmatch属性强制校验，避免 HTML 被误当 PDF 渲染：<object data="doc.pdf" type="application/pdf" typemustmatch><p>PDF 加载失败</p></object>
object嵌入SVG后无法直接操作内部元素
object 加载 SVG 会创建一个隔离的 DOM 上下文，主页面 JS 无法直接访问其内部节点。即使同源，contentDocument 也需手动获取且易为空；跨域则必然被拒绝。很多人试图用 document.querySelector('object').contentDocument.querySelector('circle') 绑定点击事件，结果是 TypeError: Cannot read property 'querySelector' of null。
立即学习“前端免费学习笔记（深入）”；
使用场景限制：
- SVG 内含
<script>或内联onclick，在object中仍可运行，但无法与主页面通信 - 若 SVG 引用了外部图标（如
<use href="icons.svg#home"></use>），跨域请求会失败，且不触发 error 事件 - 设
width/height会覆盖viewBox缩放行为，响应式布局建议用100%或不设，由父容器控制尺寸
实操建议：
- 需要 JS 控制交互时，优先改用
<img src="chart.svg">或内联 SVG（<svg>...</svg>） - 必须用
object时，通过 URL 参数传参（如data="chart.svg?theme=dark&size=large"），并在 SVG 内部 JS 解析 - 降级方案别嵌套
<img>在object内部——它只是 fallback 内容，不会自动加载，应由 JS 检测失败后手动插入
object加载HTML片段实际是独立文档，不是“动态表格”
有人把 <object data="table.html"></object> 当作“动态加载表格”，这是误解。object 加载的 HTML 是完整、隔离的文档上下文：它的 CSS 不继承主页面样式，JS 全局变量不共享，滚动区域独立，DOM 无法被主页面 querySelector 选中。你看到的“表格”只是另一个页面被框在矩形区域内，和你的主页面表格毫无关系。
容易踩的坑：
- 给
object设置class="my-table"并在主 CSS 里写.my-table td { color: red; }→ 完全无效 - 在主页面执行
document.querySelector('object').contentDocument.querySelector('table')→ 同源下可能拿到，但多数情况返回null（尤其移动端） - 期望
object高度随内部 HTML 内容自适应 → 实际需固定height或 JS 测量，且 iOS Safari 常卡住高度计算
实操建议：
- 真要复用 HTML 片段，用
fetch+innerHTML注入更可控：fetch('table.html').then(r => r.text()).then(html => el.innerHTML = html) - 若坚持用
object，仅限展示型内容（如帮助文档、静态说明页），放弃样式/脚本联动预期 - 不要指望
<param>传参生效——现代浏览器已废弃该机制，<param name="src" value="xxx">对任何现代资源类型都无意义
移动端object fallback基本失效，别依赖
兜底
在 iOS Safari、微信内置浏览器、QQ 浏览器等主流移动端环境里，<object data="doc.pdf" type="application/pdf"><p>请下载</p></object> 中的 <p> 几乎从不显示。浏览器要么调起系统 PDF 应用，要么静默失败，连控制台都不报错。这是因为现代移动端已将 type="application/pdf" 视为“交由系统处理”的信号，绕过了 HTML fallback 流程。
关键细节：
- 删掉
type属性，object在移动端大概率降级为纯下载链接，而不是渲染 fallback -
#page=5这类 URL 参数在 iOS Safari 和部分安卓 WebView 中被忽略，PDF 总是打开第一页 -
error事件在 PDF 加载失败时也常不触发，无法靠它做降级判断
实操建议：
- 移动端 PDF 嵌入，请直接用
<iframe src="doc.pdf"></iframe>—— 它不走插件协商流程，兼容性好得多 - 若必须支持旧安卓 WebView 或定制内核，fallback 检测得靠 JS：
if (obj.offsetHeight === 0) { /* 插入下载链接 */ } - 永远不要把
<noembed>当 fallback 用——所有现代浏览器已彻底忽略它
真正麻烦的不是写错 data 或漏写 type，而是你以为 fallback 会兜底、contentDocument 可以取到、SVG 里的 JS 能和主页面通信——这些在现代浏览器里，大多只是“看起来应该行”，实际一跑就断。
