HTML5的play()函数不控制预加载，卡顿因资源未就绪；preload属性（none/metadata/auto）决定预加载策略，需结合用户交互与canplay事件确保可靠播放。
HTML5 的 play() 函数本身不支持预加载控制——它只是触发播放，预加载行为由 preload 属性和浏览器策略共同决定。
为什么调用 play() 后视频还是卡顿？
常见现象是：页面一加载就调用 video.play()，但实际播放延迟高、报错或静音失败。根本原因不是 play() 有问题，而是媒体资源尚未准备好，且浏览器未按预期预加载。
-
play()不会强制下载数据，它只向浏览器发出“现在想播”的信号 - 若
preload设为"none"或网络慢，play()会立即进入pending状态，直到canplay或canplaythrough事件触发 - 移动端（尤其是 iOS）默认禁止自动播放带声音的媒体，即使预加载了，
play()仍可能被拒绝并抛出NotAllowedError
preload 属性的三个取值怎么选？
preload 是 标签的原生属性，影响浏览器是否以及如何预加载媒体，和 play() 无直接调用关系，但决定 play() 能否快速响应：
-
preload="none"：完全不预加载，首次play()时才开始请求文件——适合大文件或用户点击率低的场景 -
preload="metadata"：只加载头信息（时长、尺寸、封面帧），不加载音视频数据——最常用，平衡速度与流量 -
preload="auto"：建议浏览器尽可能预加载全部内容——但浏览器可忽略（尤其在移动网络下），且可能被用户设置覆盖
注意：preload 是提示（hint），不是强制指令；Chrome 和 Safari 对 "auto" 的实际行为差异较大，iOS Safari 基本无视 "auto"。
立即学习“前端免费学习笔记（深入）”；
怎样让 play() 更可靠？关键时机与兜底逻辑
不能依赖“一上来就 play()”，而要等资源就绪 + 用户交互授权（尤其有声媒体）：
- 监听
canplay事件再调用play()，比loadeddata更早，适合需要快速响应的场景 - 对有声音的视频，必须确保调用
play()发生在用户手势（如click、touchstart）回调中，否则现代浏览器会拒绝 - 捕获错误并降级：
video.play().catch(e => { if (e.name === 'NotAllowedError') { console.log('需用户交互后才能播放'); } }); - 如果真需要“后台预加载”，可用
fetch()+Blob+URL.createObjectURL()手动加载并赋给src，但这绕过了原生preload机制，且无法利用 HTTP 缓存和 range 请求
真正影响预加载效果的是 preload 属性、网络条件、用户权限状态，而不是 play() 函数本身。很多人试图用 JS “调用多次 play()” 来“催加载”，这毫无意义——浏览器不会因此多下一块数据。重点永远在资源准备阶段的配置与时机判断上。
