移动端HTML音频不自动播放是因浏览器策略拦截；iOS Safari仅认原生button或role="button"+tabindex="0"的同步click事件，autoplay+muted在iOS仍需首次用户点击，安卓WebView需显式声明source的type属性并避免相对路径。
移动端 HTML 音频不自动播放，不是你代码写错了，而是浏览器（尤其是 iOS Safari 和 Android WebView）主动拦截了——play() 调用不报错、没声音、控制台也安静，这才是最典型的策略拦截表现。
为什么 play() 在点击后仍失败
iOS Safari 对“用户手势”的认定极其严格：它只认原生 <button></button> 元素，或带 role="button" + tabindex="0" 的元素的同步 click 事件；其他情况一律拒绝。
- 不能用
<div onclick="audio.play()"> —— 即使加了 <code>onclick，也不算可信手势 - 不能在
setTimeout、Promise.then、requestAnimationFrame里调play() - 不能绑定到
document或body上的 click，必须落在语义化按钮元素上 - 首次成功播放后，后续
play()才可能脱离手势上下文（iOS 15+ 有放宽，但别依赖） -
muted的作用是绕过「有声自动播放」拦截，不是让音频变静音后就能播 - 若想静音启动再手动开声，必须先完成一次成功的
play()，再设audio.muted = false - Chrome/Firefox/Edge 支持
autoplay muted，但 iOS 不支持，跨端方案不能以它为基准 - 必须显式声明
type：如<source src="bg.mp3" type="audio/mpeg"></source>，不能省略 - 避免相对路径（如
./bg.mp3），改用绝对路径或file:///android_asset/（原生打包时） - 调试阶段可在初始化时调用
webview.getSettings().setMediaPlaybackRequiresUserGesture(false)，但上线前必须关掉 -
preload="metadata"：只拉取时长、封面等元信息，适合背景音乐类场景，首播延迟低、带宽友好 -
preload="none"：完全不预加载，用户点播才发起请求，适合大文件或非必播资源 -
preload是字符串值，别写成preload="true"——浏览器会直接忽略
autoplay + muted 为何在 iOS 上依然无效
iOS Safari 把 muted 当作“临时静音”，而非“无声音意图”，所以即使写了 autoplay muted，首次播放仍需用户点击触发——它不认为这属于可自动播放场景。
安卓 WebView 中 DOMException: The element has no supported sources
这不是路径或文件问题，而是 WebView 默认禁用媒体解析能力，尤其在 Android 7–10 系统 WebView 或旧版 Cordova 中，即使 <source></source> 标签存在，也会因 MIME 类型未注册而拒绝加载。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
preload 值选 "metadata" 还是 "none"
preload="auto" 在移动端等于埋雷：弱网下整首 MP3 下载一半卡住，canplay 永远不触发，用户点了播放按钮也没反应。
最容易被忽略的一点：所有 play() 调用都必须处理 Promise 拒绝，否则错误静默；audio.play().catch(e => console.warn('播放失败:', e)) 不是可选项，是必选项。iOS 报的 NotAllowedError: play() can only be initiated by a user gesture 就靠这个捕获和诊断。
