oncanplay事件不可靠，无法保证视频已加载足够帧数可连续播放；应结合canplaythrough事件与readystate===4判断就绪，再监听playing/waiting/stalled等运行时状态。
oncanplay 事件不是可靠判断视频就绪的方式
直接绑定 oncanplay 属性或监听 canplay 事件，**无法保证视频已加载足够帧数可连续播放**。它只表示浏览器“认为”可以开始播放（比如已有第一帧解码完成），但实际点击播放可能卡顿、黑屏或触发 waiting。尤其在低网速、HLS/DASH 流、或 preload="none" 场景下，这个事件常过早触发。
-
oncanplay是 HTML 属性，等价于video.addEventListener('canplay', handler)，两者行为一致 - 它不区分“首帧就绪”和“足够缓冲”，也不反映后续是否持续可播
- 移动端 iOS Safari 对
canplay触发时机更保守，有时甚至不触发（尤其自动播放被拦截时）
真正可用的就绪判断：结合 canplaythrough + readyState 检查
要确认视频“大概率能播到底”，必须组合两个信号：canplaythrough 事件 + video.readyState 值为 4。前者是浏览器预估缓冲充足的信号，后者是当前实际就绪等级的权威值。
-
canplaythrough事件比canplay更晚触发，意味着内部缓冲区预计足够支持 uninterrupted playback - 但该事件仍可能误报（如网络突降），所以必须二次校验
video.readyState === 4 - 注意：若设置
preload="metadata"，canplaythrough几乎不会触发；此时只能依赖canplay+ 手动检查buffered范围
video.addEventListener('canplaythrough', () => {
if (video.readyState === 4) {
console.log('视频已就绪，可稳定播放');
}
});
监听播放状态变化要用 playing / waiting / stalled，不是 oncanplay
想响应“用户点播放后是否卡住”“是否开始流畅播放”，应监听 playing、waiting、stalled 这类运行时状态事件，而非一次性就绪事件。
-
playing：视频从暂停/加载中恢复，开始渲染帧（比canplay更贴近真实播放起点） -
waiting：播放中因缓冲不足暂停，此时需提示加载或降码率 -
stalled：浏览器尝试获取数据但长时间无进展（如 HTTP 超时），比error更早暴露网络问题 - 不要在
oncanplay里调video.play()—— iOS/Android 可能拒绝自动播放，且易触发NotAllowedError
兼容性与移动端特别处理
iOS Safari 和部分安卓 WebView 对媒体就绪判断有额外限制：即使 readyState === 4，调 play() 仍可能失败，除非由用户手势触发。
- 必须确保首次
play()调用发生在用户点击、触摸等事件回调内 - 不能依赖
canplaythrough后立即播放；可先设video.muted = true绕过静音限制（部分机型有效） - 使用
video.networkState辅助判断：值为0（EMPTY）、1（IDLE）、2（LOADING）、3（NO_SOURCE）—— 若长期卡在1，说明资源未真正发起请求
真正难的不是监听哪个事件，而是接受「就绪」本身是个概率判断：网络、设备、编码格式、CDN 响应都会让 readyState 在 3 和 4 之间反复横跳。别指望一个事件一劳永逸。
