HTML5 play() 不能无条件直接调用，必须在用户手势（如click、touchend）回调中同步调用并处理Promise返回值，否则会因权限限制被拒绝。
HTML5 play() 函数到底能不能直接调用？
不能，至少不能无条件调用。现代浏览器（Chrome 70+、Firefox、Safari）强制要求用户手势（如点击、触摸）触发 play()，否则会抛出 NotAllowedError: play() failed because the user didn't interact with the document first.
这是策略变更，不是 bug。自动播放音频/视频会干扰用户，尤其在移动端，所以浏览器默认静音拦截非用户驱动的播放请求。
- 只有用户显式操作（
click、touchstart、keydown等）后的 JS 上下文中调用play()才可能成功 -
autoplay属性本身也受限：即使写了<audio autoplay></audio>，没用户交互时多数浏览器仍不播放（仅静音播放或完全跳过） - 如果音频元素尚未加载元数据（
readyState === 0），play()会立即 reject，需监听loadedmetadata或检查readyState >= 1
怎么让 play() 在用户点击后真正生效？
关键不是“调用”，而是“确保调用时机合法 + 处理 Promise 返回值”。HTML5 play() 返回 Promise，失败时不会抛异常，而是 reject —— 必须用 .catch() 捕获，否则静默失败。
button.addEventListener('click', () => {
audio.play()
.then(() => console.log('播放启动'))
.catch(err => console.warn('播放被拒:', err.name));
});
- 必须在用户事件回调内调用，不能包裹在
setTimeout或异步函数延迟后（哪怕只延 1ms，也会脱离用户手势上下文） - 不要依赖
canplay或canplaythrough触发播放 —— 这些事件不带用户手势，调用play()依然会被拒 - 移动端注意：部分 iOS Safari 要求事件必须来自真实触摸（
touchend比click更可靠），且不能阻止默认行为（e.preventDefault()可能破坏手势链）
play() 失败后还能补救吗？
不能“重试”，但可以降级处理。一旦错过用户手势窗口，后续所有 play() 调用都会被拒，直到下一次有效交互发生。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
立即学习“前端免费学习笔记（深入）”；
- 常见做法是把播放逻辑绑定到一个始终可见的按钮上（比如“播放”图标），而不是试图在页面加载完自动播
- 若需预加载音频，可用
audio.load()或设置preload="auto"，但这不等于可播放 —— 加载完成 ≠ 播放授权 - 静音视频（
<video muted autoplay></video>）是少数允许无交互自动播放的例外，但音频不行；若业务允许，可考虑用<video></video>加透明 canvas 模拟音频播放器
为什么加了 muted 对音频没用？
因为 muted 是 <video></video> 属性，对 <audio></audio> 元素无效。HTML 规范中，muted 仅作用于视频元素，用于绕过静音限制 —— 音频元素没有这个“后门”。
-
<audio muted></audio>不报错但也不起作用，audio.muted = true同样无效 - 想实现类似效果，只能换方案：用
<video></video>标签加载无声视频（如 1px 黑帧），再通过AudioContext播放实际音频 —— 这属于跨技术栈绕过，复杂度高，一般不推荐 - 真正可控的静音控制，是调用
audio.volume = 0，但它不能解除播放权限限制
用户手势上下文是一次性的，且不可继承。写代码时最容易忽略的，就是以为“用户点过一次，之后就能随便播了”——其实每次播放都得重新绑定到新的交互事件里。
