<audio>标签是 HTML 5 的新标签。<audio>标签定义声音，比如音乐各其它音频流。公司的项目需要使用这个标签。在使用的过程中遇到了两个问题：一个是部分手机浏览器无法实现自动播放（同样也无法使用js控制实现自动播放），还有一个是部分浏览器audio标签无法正常响应ended(播放结束)事件，无法获取audio标签的duration属性的值。

1、部分手机浏览器无法实现自动播放

这个现象产生的原因是：部分浏览器考虑了安全问题（偷跑流量），所以必须用户交互后才能播放。知道了原因那么自然就很好处理了。对于这个问题，网上大多处理方式都是先监听用户的DOM操作，如果事件响应了音频还没有播放，则播放音频。而我们这边的业务需求，需要一开始就获取自动播放的权限（音频是我们应用的一个关键功能），所以我们的处理方式是页面开始就引导用户点击。

用户点击“按钮”才能进入内容页面。这里，用户点击之后才能使用我们服务。用户点击之后，我们也就获取到了js控制自动播放的权限了。如果你们的业务需求无法使用以上方式在一开始就让用户点击、获取播放权限，而且音频并非页面加载完就必须播放（例如背景音乐之类的）。那么可以先判断一下当前浏览器是否支持自动播放，如果支持则页面加载完立即播放音频，如果不支持则监听用户的DOM操作再播放音频。

这里我写一个audioPlayPlugin.js,对audio标签的常用操作进行了一些简单的封装。

2、部分浏览器audio标签不正常响应ended(播放结束)事件，无法获取audio标签的duration属性的值

因为业务需求，我必须监听音频的各种状态（播放中timeupdate、暂停pause、播放结束ended、缓冲waiting）等，但是在部分手机浏览器（例如MIUI的系统浏览器）中监听不了ended事件。也无法获取audio标签的duration属性的值（如果能够获取duration属性的值，就可以通过监听timeupdate事件，判断currrentTime和duration是否相等来模拟ended事件）。

起初看到资料说是 Response Headers的content-type属性值为audio/x-mpeg导致的（浏览器不支持x-mpeg模式），把值设置为audio/mpeg即可。然而，找到后端说了这事儿，他弄了半天把content-type属性值设为audio/mpeg，然而问题并没有解决。

最后我做了一个测试，同一个音频直接放在网站目录下用相对路径就可以正常监听ended事件，也能正常获取duration属性值。生产环境我们的文件是在阿里云上，使用绝对路径。对比了一下headers信息，发现唯一不同的地方就是Status Code不同。能正常监听的Status Code是206，不正常的是200。最后后端将音频文件的返回方式调整为206后，问题成功解决。

总结一下：发生这个问题的原因是音频类型文件请求的响应方式不对。其实默认的响应方式就是206，只是我们后端在设置文件响应方式的默认配置时，直接copy了一些配置文件，其实并不知道他修改了音频文件的响应方式。