原生标签最轻量兼容性好，但ios强制全屏、android静音自动播放失败；需加playsinline等属性，用h.264+mp4，有声播放须用户手势触发，自定义控件需监听loadedmetadata和seeked事件。
用 <video></video> 标签就能跑，但默认控件不统一
浏览器原生 <video></video> 是最轻量、兼容性最好的起点，不用加载任何 js 就能播放 MP4/H.264。但不同系统（尤其是 iOS 和 Android）对 controls 的渲染逻辑差异大：iOS 会强制全屏、禁用右键、忽略 preload；Android chrome 则可能静音自动播放失败。别指望一次写完就到处长得一样。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 必须加
playsinline属性，否则 iOS safari 会强切全屏 -
webkit-playsinline和x5-playsinline（微信/QQ 内核）也得带上，缺一不可 - MP4 视频优先用 H.264 + AAC 编码，避免用 VP9 或 AV1——Safari 仍不支持
- 如果需要封面图，用
poster属性，别用 CSS 覆盖第一帧，否则 iOS 下首帧可能黑屏
自动播放失败？大概率是没过浏览器的媒体策略校验
Chrome、Safari、firefox 都要求「用户手势触发后」才能播放有声视频。直接在 pageLoad 里调 play() 会抛 NotAllowedError: play() failed because the user didn't interact with the document first.，不是代码写错了，是规则卡死了。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 静音视频可绕过限制：
autoplay muted是安全组合，但需显式设muted=true - 若必须有声，等用户点击按钮后再调
video.play()，且该点击事件不能是委托或异步延迟的 - 不要在
setTimeout里模拟用户交互——浏览器不认 - 微信内嵌页还要额外检查
document.addEventListener('WeixinJSBridgeReady')，否则 iOS 微信里play()直接静默失败
自定义控件时，currentTime 和 duration 经常不准
视频还没加载完，duration 可能是 NaN 或 Infinity；拖动进度条后 currentTime 可能跳变、延迟更新，甚至卡在上一个值。这不是你监听错了，是浏览器媒体加载状态没同步好。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
loadedmetadata事件再读duration，别在load或canplay里取 - 进度条拖动要用
seeking+seeked配合，而不是只靠input或change - 设置
currentTime后立刻检查是否生效，失效时重试最多 1 次，别循环 set - 移动端慎用
requestVideoFrameCallback做精准时间同步——兼容性差，且耗电明显
想支持 HLS 或 MSE？别直接手写，先看目标环境
HLS（.m3u8）在 Safari 原生支持，但 Chrome 和 Firefox 不支持；dash（.mpd）相反。硬用 MediaSource + SourceBuffer 接流，等于自己实现解复用和缓冲管理，出错率高、调试成本大。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 纯 Web 端优先用
hls.js（HLS over MSE），它自动降级：Safari 走原生，其他走 MSE - 别用
videojs-contrib-hls这类老库，已停止维护，和新版 Video.js 7+ 不兼容 - 如果服务端能转封装，把 HLS 改成 MP4 分片（如通过
ffmpeg -f mp4 -frag_keyframe），直接喂给原生<video></video>更稳 - MSE 初始化前务必检查
MediaSource.isTypeSupported('video/mp4; codecs="avc1.42E01E, mp4a.40.2"')，否则报错无提示
真正难的不是播放，是应对不同设备对“播放”这件事的理解差异——iOS 认为自动播放=打扰，安卓认为静音=失效，桌面浏览器又默认允许。这些不是 bug，是设计选择。处理它们比写个播放器核心逻辑花的时间多得多。