object 标签现在无法加载任何第三方插件——Flash、Java Applet、QuickTime、ActiveX 等全部失效，不是写法问题，是底层插件宿主已被浏览器彻底移除。
为什么 object + param 在现代浏览器里必然失败
Chrome 45+、Firefox 52+、Edge 14+、Safari（更早）已移除 NPAPI/ActiveX 接口；macOS Catalina+ 禁用所有 32 位插件；Flash 官方支持已于 2020 年终止。你看到的“能跑”，基本是本地用了过时内核或降级浏览器，不具备生产环境可靠性。
-
type="application/x-shockwave-flash"或type="application/x-java-applet"会静默失败，Network 面板只显示Failed to load resource，不触发onerror -
<param>标签完全不被解析——它依赖的插件运行时已不存在，name="movie"或name="flashvars"不会被读取 - 即使 HTML 结构完全合规，
classid和codebase也仅对 IE11 内网 ActiveX 场景有意义，且需启用兼容性视图
object 的真实生命周期：只有加载失败才“启动”
object 没有传统意义上的“插件生命周期”（如 init → start → pause → destroy），它只有两个状态：资源可加载并渲染成功，或不可用而降级到 fallback。这个切换由浏览器在加载链路中多个环节判断，不是 JS 可控的。
- 触发 fallback 的条件包括：
data返回 404 / CORS 阻止 / 响应头Content-Type与type不匹配 / 资源加载超时 / 用户禁用插件 - 不会触发 fallback 的情况：PDF 文件存在但权限受限（如加密或跨域 iframe 嵌套）、SVG 加载成功但内部 JS 失效、
width/height为 0 导致视觉“白屏” -
onload事件只在资源加载完成且渲染就绪后触发（极少数场景，如同源 SVG）；onerror在现代浏览器中几乎不触发，不能作为容错依据
真正可用的容错路径：只针对 PDF 和同源 SVG
当前唯一稳定使用 object 的场景是嵌入 PDF，但容错必须从服务端和路径层设计，而非靠前端标签“写得漂亮”。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
-
data必须指向可访问的 URL（推荐https://或http://localhost，file://协议下多数浏览器拒绝加载） -
type必须严格为application/pdf（写成pdf、text/pdf或留空均无效） - 服务端响应头必须含
Content-Type: application/pdf；Nginx/Apache 未配置 MIME 类型会导致 fallback - 加
typemustmatch属性可强制校验响应头与type一致，避免返回 HTML 却被当 PDF 渲染 - fallback 内容必须是合法 HTML 元素（如
<p>PDF 加载失败</p>），不能是注释、空格或<script>
替代方案比硬扛 object 更实际
如果你的目标是“可靠加载外部内容并提供降级”，iframe 是更可控的选择；如果目标是交互式媒体，用 <video>、<audio> 或 Web Components 替代。
- PDF 场景优先用
<iframe src="doc.pdf"></iframe>：自动滚动、尺寸可控、错误时仍保持容器结构、支持sandbox - 需要无 JS fallback 时才考虑
object，但必须接受它只在 PDF/SVG 场景下有效，且失败原因往往不在 HTML 层而在服务端配置或协议限制 - 任何涉及用户交互、状态管理、重试逻辑的需求，都该交给 JS 控制——比如用
fetch()预检 PDF 是否可访问，再决定渲染object还是提示下载
复杂点从来不在怎么写 object，而在搞清它什么时候根本不会发起请求：路径拼错、协议不匹配、MIME 类型缺失、CORS 未配——这些才是 fallback 不出现的真正原因。
