HTML多媒体交互控制的核心是围绕video/audio元素原生API进行状态监听与方法调用；controls属性无法替代JS控制，因其黑盒特性、iOS全屏强制、事件不可控，且缺乏缓冲查询、多实例同步等能力。
直接说结论：HTML 多媒体交互控制的核心不是写一堆按钮，而是围绕 <video> 和 <audio> 元素的原生 API 做状态监听与方法调用——所有自定义控件都只是对 play()、pause()、currentTime、volume 等属性/方法的封装。
为什么 controls 属性不能替代 JavaScript 控制
浏览器自带的 controls 是黑盒：你无法监听它内部的播放进度变化，也不能在用户拖动进度条时插入自己的逻辑（比如打点埋点、同步字幕、限制倍速）。更关键的是，controls 在 iOS Safari 上会强制全屏，且不响应 pointerdown 事件，导致自定义 UI 覆盖失效。
- 想做进度同步字幕？必须监听
timeupdate事件，而不是依赖controls - 需要禁用快进到未缓冲区域？
controls完全不提供缓冲区查询接口，得靠buffered属性手动判断 - 想统一管理多个媒体实例的播放状态（比如“暂停其他正在播放的音频”）？
controls每个独立运行，互不可知
play() 被静音策略拦截的典型场景
现代浏览器（Chrome、Safari、Firefox）普遍要求用户手势触发首次 play()，否则抛出 NotAllowedError。这不是 bug，是策略——自动播放音频会被视为骚扰。
-
autoplay+muted可绕过限制，但仅限视频；纯<audio>即使muted也大概率被拒 -
click或touchstart事件回调里调用play()才安全；setTimeout延迟后调用就失效 - iOS Safari 对
play()的手势上下文要求最严：必须是用户直接触发的事件链，不能经 Promise.then 或 async/await 中转
自定义进度条拖拽的坑：别直接绑 input 事件
用 <input type="range"> 做进度条很常见，但直接监听 input 事件更新 currentTime 会导致卡顿、跳帧，尤其在低性能设备上。
立即学习“前端免费学习笔记（深入）”；
- 正确做法是监听
change事件（用户松手后才生效），避免频繁写入currentTime - 拖拽过程中需同步显示预览（如 tooltip 显示时间戳），但不要实时改
currentTime，否则和播放器原生逻辑冲突 - 设置
currentTime前先检查duration是否已加载（duration === Infinity表示还没解析完元数据），否则会静默失败
真正难的不是实现播放/暂停，而是处理缓冲中断、跨域音视频的 CORS 限制、不同格式的编码兼容性，以及 iOS 上那个永远不告诉你为什么失败的 play() 错误——这些细节不会出现在教程代码里，但线上问题八成出在这儿。
