oncanplay仅表示首帧可渲染，不保证可自动播放；需用户手势触发play()并配合muted、错误处理等策略才能成功。
oncanplay 不是“可以播放”的开关，它只是个信号——表示视频元数据已加载、首帧可渲染，但此时调用 play() 仍可能被浏览器策略拒绝（比如没用户交互、没静音）。真想自动播，得配合条件和错误处理。
oncanplay 触发时直接调用 play() 为什么经常失败
常见错误现象：play() 报 NotAllowedError，控制台显示“play() failed because the user didn't interact with the document first”，但页面明明已触发 oncanplay。
-
oncanplay只说明资源就绪，不等于浏览器允许自动播放 - Chrome/Firefox/Safari 等现代浏览器强制要求：首次
play()必须由用户手势（如click、touchstart）触发 - 即使监听了
oncanplay，如果是在页面加载后无交互时立即调用play()，大概率被拦截 - 移动端更严格，部分 Android WebView 甚至忽略
muted也拒播
正确绑定 oncanplay 并安全调用 play()
关键不是“绑了就能播”，而是“等用户点一下再播”。典型做法是：先监听 oncanplay 存状态，等用户触发一次交互后再 play()。
- 设置
video元素的autoplay muted属性（仅作为 fallback，非必需） - 在 JS 中监听
canplay事件，设一个标志位isCanPlay = true - 绑定一次用户点击（如播放按钮），点击回调里检查
isCanPlay，为真则调用play()并catch错误 - 避免在
oncanplay回调里直接play()，除非你确认此前已有用户交互（比如该视频是点击某个卡片后动态插入的）
addEventListener("canplay", ...) 和 oncanplay= 的区别
两者都能监听，但行为差异影响调试和维护：
-
oncanplay = handler是属性赋值，同一时间只能有一个 handler；重复赋值会覆盖前一个 -
addEventListener("canplay", handler)支持多次绑定，适合模块化代码或第三方 SDK 注入逻辑 - 推荐用
addEventListener，尤其当视频元素可能被多次重用（如切换 src 后重新监听） - 注意：每次更换
src后，需重新绑定canplay监听器，否则事件不会触发（因为旧监听绑定在旧加载流程上）
canplay 和 canplaythrough 到底该选哪个
别只看名字，看实际场景：
-
canplay：首帧可渲染即触发，适合“尽快开始播”，但可能播几秒就卡住缓冲 -
canplaythrough：浏览器预估能不中断播完才触发，更可靠，但延迟高（尤其大视频或弱网） - 如果视频短（canplay + 用户交互兜底
- 如果对首屏体验要求不高、更看重一次播完，用
canplaythrough更稳妥 - 两者都不解决“自动播放策略”问题，该加
muted还得加，该等点击还得等
最容易被忽略的一点：监听 canplay 前必须确保 src 已设置。DOM 加载完再设 src，再立刻 addEventListener，中间不能有异步 delay；否则事件可能在监听前就已触发并丢失。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
