onplay事件在媒体真正开始播放（解码完成、首帧渲染）时触发，非点击瞬间；常因autoplay被拦截、绑定过早或未处理play() Promise而失效，推荐用addEventListener监听且优先选用playing事件标识画面实际渲染。
onplay 事件不是“点击播放时触发”，而是**媒体真正开始播放（解码完成、首帧渲染）后触发**。很多人绑了却收不到，是因为误以为它等同于用户点击了播放按钮。
为什么onplay经常不触发？
常见原因有三个：
-
autoplay被浏览器拦截（尤其移动端或无用户交互前提下），视频卡在“加载中”状态，根本没进入播放流程 - 绑定时机太早：DOM 节点还没加载完，
document.getElementById('myVideo')返回null - 用了内联写法但函数未定义或作用域不对，比如
<video onplay="handlePlay()">中handlePlay是模块里声明的，全局不可见
addEventListener('play', ...) 是更可靠的写法
相比内联 onplay 属性，addEventListener 更灵活、可叠加、易维护，且能明确控制绑定时机。
- 必须等
<video>元素就绪后再绑定，推荐放在DOMContentLoaded里 - 不要监听
click后再手动调.play()并期望立刻触发play事件——.play()返回的是 Promise，需await或.then()确认播放真正启动 -
play事件不冒泡，所以父容器监听不到，也不用担心干扰
示例：
document.addEventListener('DOMContentLoaded', () => {
const video = document.getElementById('myVideo');
if (video) {
video.addEventListener('play', () => {
console.log('✅ 实际播放已开始（非点击瞬间）');
// 这里适合更新 UI 状态，比如切换暂停图标
});
}
});
移动端和自动播放场景要特别注意
iOS Safari 和多数 Android 浏览器默认禁止无交互 autoplay，即使写了 autoplay 属性，play 事件也不会触发，直到用户主动点击。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 检查
video.paused和video.ended状态，别只依赖play事件判断是否“正在播” - 如果需要响应用户点击行为，优先监听
click或touchstart（移动端用touchstart避免 300ms 延迟），然后调.play()并处理其返回的 Promise -
play()失败会抛出异常（如NotAllowedError），记得用try/catch或.catch()
别混淆 play 和 playing 事件
play 表示“播放请求已发出、准备开始”，而 playing 才表示“已解码并正在持续渲染帧”。两者触发时机不同：
-
play在调用.play()后立即（同步）触发，哪怕还在缓冲 -
playing要等到第一帧画面实际渲染出来才触发，更适合做“播放中”的精确标记 - 若要做播放状态同步（比如按钮变暂停），用
playing比play更稳妥
所以，真要反映“画面动起来了”，建议监听 playing：
video.addEventListener('playing', () => {
console.log('? 第一帧已渲染，播放器真正跑起来了');
});
onplay 表面简单，但背后牵扯 autoplay 策略、Promise 异步流程、事件触发时机差异。最容易被忽略的是：它不等于“用户点了播放”，也不保证“画面已出现”。 
