type属性必须显式声明且与响应头content-type严格匹配，否则直接fallback；pdf须用application/pdf，svg须用image/svg+xml，html须用text/html，且服务端响应头必须正确配置。
type 属性必须显式声明且与响应头严格匹配
浏览器不会根据 data 路径后缀（如 .pdf）自动推断类型，它只信任 type 属性值，并拿它跟服务器返回的 Content-Type 响应头比对。不一致就直接 fallback，哪怕文件本身完全正常。
常见错误现象：<object data="report.pdf" type="pdf"></object> 或 type="" —— 这两种写法 Chrome/Firefox 都无视，直接留白；type="application/x-pdf" 也不行，必须是标准 MIME 类型 application/pdf。
- PDF 必须用
application/pdf - SVG 必须用
image/svg+xml（不是text/xml或application/xml） - HTML 文档必须用
text/html（注意不是application/xhtml+xml） - 不要写
type="image/png"却让data指向 JPG——这是人为触发 fallback
typemustmatch 属性会强制校验，但默认不启用
加了 typemustmatch 属性后，浏览器会在 type 和响应头不一致时立刻 fallback；不加则部分浏览器（如旧版 Firefox）可能忽略响应头、仅按 type 尝试加载。这不是“宽松”，而是行为不可控。
真实使用建议：
- 开发调试阶段加上
typemustmatch，能快速暴露服务端 MIME 配置错误 - 生产环境若依赖 fallback 内容（如降级为
<img>），建议保留该属性，避免静默失败 - 本地
file://协议下该属性无效——必须用http://localhost启服务预览
服务端 Content-Type 响应头不能错，尤其 PDF 和 SVG
即使你写了正确的 type，如果服务端返回 PDF 文件时响应头是 Content-Type: text/plain 或 application/octet-stream，Chrome 和 Firefox 仍会 fallback。这不是前端能绕过的。
检查方法：打开 DevTools → Network → 点开对应请求 → 查看 Response Headers 中的 Content-Type。
- Nginx 配置示例：
types { application/pdf pdf; }+ 确保default_type application/pdf;不覆盖它 - Python Flask 示例：
return send_file("doc.pdf", mimetype="application/pdf") - 静态托管平台（如 Vercel、Netlify）需通过
_headers文件或构建配置显式设置
SVG 和 PDF 的 type 设置差异直接影响交互能力
type="image/svg+xml" 加载的 SVG 是独立文档上下文，支持内部 JS、CSS 和 DOM 操作（同源前提下可通过 object.contentDocument 访问）；而 type="application/pdf" 加载的 PDF 是只读渲染层，contentDocument 为 null，也无法注入脚本。
这意味着：如果你需要 SVG 图表响应点击事件，type 写错会导致整个交互逻辑失效，且控制台无报错——只是没反应。
- SVG 场景务必用
image/svg+xml，别用text/xml（解析失败）或漏写type（降级为 img） - PDF 场景不要幻想用 JS 控制页面跳转——那是 PDF 查看器自己的事，
type错了连查看器都唤不起 - 两者都必须配
width/height：Safari 16+ 对 PDF 强制要求尺寸才触发内建查看器；SVG 缺尺寸则可能缩放异常
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
