video标签不支持原生列表播放，需用JavaScript控制单个video元素切换src并监听ended事件实现；必须调用load()等待loadedmetadata后再play()，且自动播放需设muted=true；不同平台兼容性差异大，需针对性处理。
video标签本身不支持列表播放，必须靠JavaScript控制
HTML的 <video> 是单实例元素，没有内置“下一个”“上一个”或“自动跳转”逻辑。所谓“视频列表播放”，本质是用JS切换 src 属性并调用 load() 和 play()，同时监听 ended 事件触发下一项。
常见错误是直接写多个 <video> 标签并试图用CSS隐藏/显示——这会浪费资源、引发预加载冲突，且无法保证播放状态同步。
- 只保留一个
<video>元素作为播放容器 - 用数组或对象管理视频元数据（
src、标题、时长等） - 每次切换前调用
videoElement.pause()防止音频残留 - 在
ended事件里判断索引是否越界，避免静音播放失败后卡住
如何安全切换video.src并避免黑屏/报错
直接赋值 video.src = newUrl 后立刻 play()，常遇到 NotAllowedError 或首帧黑屏。这是因为浏览器策略要求用户交互后才能启动媒体播放，且新资源需重新加载元数据。
正确做法是：先设置 src，再调用 load()，等待 loadedmetadata 事件后再 play()。若需静音自动播（如信息屏），必须加 muted 属性。
立即学习“前端免费学习笔记（深入）”；
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
video.muted = true是自动播放的前提（尤其Chrome 70+） - 不要省略
load()—— 否则可能沿用旧缓冲，导致duration错误或seekable范围异常 - 监听
error事件，检查video.error.code（如4表示网络错误） - 移动端Safari对自动播放更严格，建议首次播放由用户点击触发
实现循环/顺序/随机播放模式的关键逻辑
播放模式不是靠属性开关，而是靠 ended 事件中对当前索引 currentIndex 的计算方式。核心在于别硬编码逻辑，把模式抽象成函数。
例如顺序播放：当前索引 +1，超限时停止；循环播放：用取模 (currentIndex + 1) % list.length；随机播放：生成不重复的随机序列或允许重复的 Math.floor(Math.random() * list.length)。
- 避免在
ended中直接修改currentIndex后立即load()—— 应封装为异步函数，防止事件重入 - 用户手动点击“下一集”时，要清除上一个
ended监听器或加标志位，否则可能触发两次加载 - 若视频有字幕（
<track>），切换时需同步更新srclang和label，否则字幕不显示
移动端兼容性与性能必须处理的细节
iOS Safari 和 Android Chrome 对 <video> 的行为差异极大：iOS 强制全屏播放、禁止后台音频、autoplay 基本无效；Android 则可能因WebView内核版本不同导致 canplaythrough 不触发。
实际项目中，这些细节比功能逻辑更耗时：比如用户滑动列表时预加载下一项的缩略图（用 poster），但别预加载视频本身；又比如监听 visibilitychange 暂停播放，切回前台后恢复——否则iOS会静音且无法重连。
- 永远用
video.readyState >= 2判断是否可播放，而非仅靠canplay事件 - 避免在
scroll中频繁调用load()，容易触发浏览器限流 - 安卓低端机上，连续切换视频可能因内存不足崩溃，建议加
video.src = ''清空上一个资源引用
实际做下来，最难的不是写播放逻辑，而是让不同设备在各种网络和用户操作路径下都“不卡、不黑、不报错”。很多问题只在真机测试时暴露，比如iOS微信内置浏览器对 muted autoplay 的额外拦截，得靠 touchstart 延迟100ms再触发首次播放。
