用单个元素实现可点击切换的视频列表，通过data-src绑定资源、preload="metadata"优化加载、首次静音播放+点击后取消静音来绕过自动播放限制，并确保play()在用户手势同步回调中调用。
用 <video></video> 标签实现可点击切换的视频列表
直接用原生 HTML + 少量 JS 就能做出基础但可用的视频列表页，不需要框架或插件。核心是让每个 <video></video> 元素共享同一播放器容器，点击列表项时只更新 src 和重置播放状态。
常见错误是为每个视频都写一个独立 <video></video> 标签并隐藏/显示——这样会浪费内存、触发多次加载、且在 Safari 上容易卡顿或静音失效。
- 只保留一个
<video></video>元素作为“播放器”，放在页面显眼位置 - 视频列表用
<ul></ul>+<li>或<div> 实现，每项带 <code>data-src、data-title等自定义属性 - 点击时调用
videoEl.src = item.dataset.src，再执行videoEl.load()和videoEl.play() - 注意：Safari 对自动播放限制严格，首次交互后才能调用
play()；若用户未点击过页面任意位置，直接调用会抛出NotAllowedError - 给
<video></video>加上muted和autoplay属性（仅用于首次加载占位） - 在
click事件里设置videoEl.muted = false，再调用play()（此时已有用户手势） - 如果视频本身没声音，可省略
muted，但建议仍加muted避免部分安卓 WebView 的兼容问题 - 不要依赖
canplay或loadeddata后立刻play()，这些事件不构成“用户手势”，依然会被拦截 - 配合
poster属性使用：每个列表项可预设缩略图 URL，点击前就展示，提升视觉反馈 - 如果后端支持 HTTP Range 请求，
metadata加载极快；否则可能退化为下载整个文件头（仍远小于全量） - 移动端弱网下，这个设置能明显减少白屏等待时间
解决 Chrome/Firefox 自动播放被拦截的问题
现代浏览器默认禁止无用户手势触发的音频/视频自动播放，尤其带声音的视频。即使你写了 autoplay 属性，也大概率失效。
可行做法是：先静音播放，等用户点击后再取消静音。这既绕过策略，又符合用户体验预期。
用 preload="metadata" 平衡加载速度与带宽消耗
preload 属性影响浏览器是否提前加载视频元数据（时长、尺寸、封面帧），对列表页体验很关键。设成 "auto" 会让所有视频预加载，浪费流量；设成 "none" 则每次点击都要等加载，卡顿明显。
推荐统一设为 preload="metadata"，它只请求视频头部几十 KB，能快速获取时长、封面图，同时避免下载完整文件。
处理 iOS Safari 的特殊限制：无法通过 JS 触发 play() 除非有用户手势
iOS Safari 是最严格的环境：不仅禁止自动播放，还要求 play() 必须发生在用户真实点击/触摸事件回调内（不能是 setTimeout 延迟、不能是 Promise.then 里调用）。
最容易踩的坑是把播放逻辑封装成函数后，在异步上下文中调用，比如：
listItem.addEventListener('click', () => {
// ✅ 正确：play() 在事件回调第一层
video.play();
});
// ❌ 错误示例（常见）：
listItem.addEventListener('click', async () => {
await fetchMeta(); // 这会导致 play() 不在原始手势作用域内
video.play(); // 被拒
});
- 所有播放操作必须在事件处理器的同步执行路径中完成
- 如需异步加载信息（如字幕、标题），请先用
load()加载资源，再在loadeddata回调里调用play()—— 但该回调本身不算用户手势，所以仍需确保play()调用链不脱离原始事件 - 简单方案：点击后立即
play()（哪怕还没加载完），靠preload="metadata"和服务端优化降低首帧延迟
