type属性不触发加载，仅在资源成功加载且响应头返回Content-Type后参与渲染决策；服务端响应头决定PDF是否内嵌或下载，type只是提示而非指令。
type 属性本身不触发加载、不校验路径、也不决定成败——它只在资源已成功加载且响应头返回 Content-Type 后，参与浏览器的“渲染决策协商”。多数人把它当开关用，结果 fallback 总不出现，PDF 突然下载而不是内嵌，SVG 闪退没报错。根本原因：误判了它的作用边界。
为什么 type="application/pdf" 写对了，PDF 还是下载而不是显示？
关键不在 type，而在服务端返回的 Content-Type 响应头。Chrome/Firefox/Safari 都以响应头为准：type 只是提示，不是指令。
- 服务端返回
Content-Type: application/octet-stream或text/plain→ 浏览器无视type="application/pdf"，直接下载 - 服务端返回
Content-Type: application/pdf→ 即使type缺失或写错（如type="pdf"），现代浏览器仍会尝试内嵌 - Nginx/Apache 默认不为
.pdf文件设置正确 MIME 类型，需手动配置：add_type application/pdf .pdf;
type 值写错或留空时，fallback 为什么经常不生效？
fallback 不是“加载失败兜底”，而是“加载成功但无法渲染”时才触发。如果 type 错得离谱（比如 PDF 写成 image/png），部分浏览器可能跳过内置 PDF 查看器匹配逻辑，直接放弃渲染——但不会进 fallback，而是留白或显示占位框。
- 推荐始终显式声明
type，哪怕只是保险：PDF 用application/pdf，SVG 用image/svg+xml，PNG 用image/png - 空
type或缺失type在某些旧环境（如 IE11 + ActiveX）下会导致插件不调用；现代浏览器虽兼容，但降低 fallback 触发概率 -
type="application/x-shockwave-flash"这类已淘汰值，现代浏览器完全忽略，但不会报错，也不会激活任何 fallback —— 它只是静默失效
哪些 type 值在现代浏览器中仍有实际影响？
真正起作用的 type 值非常有限，集中在三类：
立即学习“前端免费学习笔记（深入）”；
-
application/pdf：触发内置 PDF 查看器（Chrome/Firefox/Safari），但依赖服务端响应头匹配 -
image/svg+xml：确保 SVG 以文档模式加载（支持 JS 交互、CSS 样式、DOM 操作），而非当作静态图片；写成image/svg无效 -
text/html：配合data指向另一个 HTML 文件时，启用 iframe-like 的嵌入行为（注意同源限制与 CSP） - 其他如
audio/mpeg、video/mp4已被<audio>/<video>专属标签接管，<object>中基本无意义
最常被忽略的一点：type 的价值不在“让东西显示”，而在“让东西按预期方式显示”——比如 SVG 是否可点击、PDF 是否可搜索、HTML 片段是否能执行脚本。它不解决加载问题，但决定了加载之后的上下文环境。漏掉它，有时看不出差别；一旦业务需要交互能力，问题就浮出水面。
