type属性必须为application/pdf且服务端响应头Content-Type严格匹配，否则object标签将失败或触发fallback；其他MIME类型如text/plain、application/octet-stream或漏写type均不可行。
type属性必须匹配真实资源类型，否则多数浏览器直接拒载
浏览器看到 type 属性时，会严格比对它和实际响应头中的 Content-Type。两者不一致，<object> 就会失败——不是显示空白，就是触发 fallback 内容，甚至静默降级。这不是兼容性问题，是强制校验。
- PDF 文件必须用
application/pdf，不能写成text/plain或漏掉 - Word 文档（.docx）理论上对应
application/vnd.openxmlformats-officedocument.wordprocessingml.document，但现代浏览器基本无视该 type，只认下载行为 - SVG 文件用
image/svg+xml；PNG 用image/png；MP4 视频用video/mp4 - 如果服务端返回的
Content-Type是application/octet-stream（常见于未配置 MIME 的静态服务器），哪怕你硬写type="application/pdf"，浏览器也大概率不渲染
查不到MIME类型？别猜，用curl或开发者工具确认
靠文件扩展名推断 type 值是高危操作。很多服务器对 .pdf 返回 application/octet-stream，对 .docx 返回 text/plain，这时你写的 type 再“标准”也没用。
- 用命令行验证：
curl -I https://example.com/report.pdf，看响应头里的Content-Type - 在浏览器开发者工具 Network 标签页里点开资源请求，直接看 Response Headers 下的
Content-Type - 本地开发时，若用 Python
http.server，它默认不发正确 MIME；Node.js 的serve或 Nginx 则通常配置完善
PDF嵌入最稳妥的type值就是application/pdf，但得配合服务端
想让 PDF 在 <object> 里正常打开，type="application/pdf" 是唯一可靠选项，但前提是服务端真返回这个类型。否则 fallback 文字会永远显示，用户点开链接也只会下载。
- Apache 用户加一行：
AddType application/pdf .pdf到.htaccess或主配置 - Nginx 用户在 server 块里加：
types { application/pdf pdf; } - 用 PDFObject 库时，它内部仍依赖
<object data="..." type="application/pdf">，所以服务端问题不解决，库也白搭 - 注意：Chrome 和 Edge 自带 PDF 查看器，Firefox 需要启用内置 PDF.js（默认开启），Safari 对
object嵌入 PDF 支持较弱，常退化为下载
Word、Excel等Office文档不建议用object + type强行加载
写 type="application/vnd.openxmlformats-officedocument.wordprocessingml.document" 看起来规范，但毫无实际意义。主流浏览器已移除对 Office MIME 类型的内置处理能力，既不渲染，也不报错，只是安静地 fallback 到内部文本。
立即学习“前端免费学习笔记（深入）”；
- IE 旧版 + ActiveX 曾支持，但现在已无现实部署价值
- 真正可用的方案只有两个：转成 PDF 后用
application/pdf；或用 Office Online 提供的 iframe 嵌入链接（需公网可访问 + CORS 允许） - 如果非要原格式展示，
<embed src="report.docx">和<object data="report.docx">行为几乎一致——都是触发下载，type属性形同虚设
Content-Type 和你写的 type 属性必须咬合，否则 <object> 就是纸面协议。很多人卡在这一步，却去调前端 JS 或换标签，方向全错了。 
