应使用<audio>而非<object>嵌入音频，因后者依赖已淘汰的插件机制，在现代浏览器中普遍失效；<audio>需添加controls属性、多格式<source>及正确MIME类型，并注意服务器响应头配置。
别用 <object> 嵌入音频播放器 —— 它已过时、不可靠，且现代浏览器基本不支持音频插件回退机制。
为什么 <object> 不该用于音频嵌入
HTML 的 <object> 标签设计初衷是通用外部资源容器（如 PDF、Flash、旧版 Windows Media Player），不是为音频播放优化的。它依赖浏览器安装对应插件（如 QuickTime、WMP ActiveX），而 Chrome 自 2015 年起彻底移除 NPAPI 插件支持，Firefox 也于 2021 年终止；Safari 对非 Apple 签名插件限制极严。实际测试中，<object> 在 99% 的现代桌面/移动端环境里要么空白、要么报 Plugin not found 或直接静默失败。
常见错误现象包括：
- 页面无任何控件显示，控制台无报错（最危险：你以为“没写错”，其实是被忽略）
- 加载后显示“无法加载插件”或灰色占位框
- 即使勉强加载，
play()调用抛出NotAllowedError或完全无响应
<audio> 是唯一推荐方案，且必须带 controls 和多格式 <source>
HTML5 <audio> 是当前唯一跨浏览器、无需插件、可编程控制的标准方案。关键点不是“能不能放”，而是“怎么放才不崩”：
立即学习“前端免费学习笔记（深入）”；
- 必须显式添加
controls属性，否则默认不渲染任何 UI（不像<video>至少有 poster 占位） - 不要只写一个
src，用<source>提供至少两种格式：.mp3（兼容性最广） +.ogg或.wav（Firefox/Safari 部分版本对 MP3 解码有 licensing 限制） - 避免单独依赖
autoplay：Chrome/Safari 会拦截未静音的自动播放，加muted才可能生效；若需带声自动播，必须先触发用户手势（如 click）再调play() -
preload="metadata"比auto更友好 —— 减少首屏流量，尤其对移动用户
示例：
<audio controls preload="metadata" muted> <source src="music.mp3" type="audio/mpeg"> <source src="music.ogg" type="audio/ogg"> Your browser does not support the audio element. </audio>
如果真要兼容 IE8–IE11（极少数政企内网场景）
IE8–10 不支持 <audio>，但也不支持现代 <object> 音频方案。此时唯一可行路径是降级为 Flash fallback（已淘汰）或彻底放弃音频功能。强行用 <object classid="CLSID:...WMP..."> 写法：
- 仅在 IE 旧版有效，Edge 及所有新版浏览器无视
- 需要用户本地安装 Windows Media Player，且启用 ActiveX（默认禁用）
- 路径必须是绝对 URL 或 intranet 共享路径，
file://协议下大概率被安全策略拦截 - 控制逻辑无法用 JS 统一管理，
play()、pause()等方法在不同 IE 版本中行为不一致
结论：除非你明确锁定某台 Win7+IE11 内网机器，否则写这个就是在制造维护黑洞。
容易被忽略的兼容性细节
很多开发者以为“加了 <source> 就万事大吉”，但实际卡点常出现在：
-
type属性值必须精确匹配 MIME 类型（如audio/mpeg，不是audio/mp3），否则 Safari 可能跳过该源 - 服务器未正确配置音频文件的 Content-Type 响应头（例如返回
text/plain），会导致 Firefox 拒绝加载 - 使用
loop时，部分 Android WebView 在循环衔接处有 100–300ms 静音间隙，无法通过 JS 修复，只能换更短的音频片段或接受 -
webkit-playsinline playsinline对音频无效（这是<video>的 iOS 专用属性），音频永远无视觉容器，别白费劲
真正该花时间的地方，是验证服务器响应头、检查控制台 Network 面板里音频请求的状态码和 MIME 类型，而不是调试 <object> 的 classid 参数。
