HTML视频无原生防投屏机制，所谓“防投屏”实为应用层伪策略；监听webkitpresentationmodechanged等事件不仅无效（无法感知Miracast/AirPlay），还会导致首帧延迟、canplay不触发、缓冲清空及软解回落等问题。
HTML 视频本身没有“防投屏”属性或机制，所谓“防投屏”是应用层策略，不是浏览器标准能力。强行在前端加拦截逻辑（比如监听 webkitpresentationmodechanged 或禁用 display: none 切换）反而会干扰视频加载流程，导致首帧延迟、canplay 事件不触发、甚至触发多次 load()。
为什么“防投屏”代码会让视频变慢
很多团队误以为监听投屏状态就能阻止内容外放，于是写类似这样的逻辑：
video.addEventListener('webkitpresentationmodechanged', () => {
if (video.webkitPresentationMode === 'picture-in-picture') {
video.pause();
}
});
问题在于：
- 该事件在 Chrome/Edge 中仅在 PiP 模式下触发，对 Miracast/AirPlay 等系统级投屏完全无感知，属于伪防护
- 事件监听器注册过早（比如 DOM 加载前），可能让浏览器推迟 video 元数据解析，尤其在 iOS Safari 中会强制降级
preload行为 - 频繁调用
pause()+load()会清空已缓冲的 SourceBuffer（如果是 MSE 场景）或重置 HTTP 缓存状态，造成重复请求 - 部分安卓 WebView 会因监听该事件而禁用硬件解码加速，直接回落到软解，首帧时间翻倍
真正影响投屏体验的是 preload 和 source 加载时机
用户点击投屏按钮时，系统会尝试从当前 <video></video> 实例抓取媒体流。如果此时视频还没完成元数据加载（readyState ），投屏端就会黑屏或报错——这不是“被防住了”，而是没准备好。
立即学习“前端免费学习笔记（深入）”；
正确做法是让视频在用户可能投屏前就进入可播放状态：
- 首屏关键视频必须设
preload="metadata"，且避免设autoplay（iOS/Android 多数浏览器会静音拦截） - 在
DOMContentLoaded后立即调用video.load()，不要等scroll或click才触发 - 若使用
<source></source>动态注入（如配合鉴权），确保在sourceopen事件后才允许投屏操作，否则 MediaSource 尚未 ready - 避免在
canplay前就绑定投屏相关 UI 控件，防止用户点出无效状态
服务端响应头比前端 JS 更关键
投屏设备（尤其是 TV 端）依赖服务端返回的完整媒体信息。如果 MP4 文件的 moov box 不在开头，或服务端没返回 Accept-Ranges: bytes，投屏端无法做 seek 或分片拉取，就会卡在 loading 状态。
检查手段（终端执行）：
curl -I https://your-cdn.com/video.mp4 # 必须看到：Accept-Ranges: bytes # 若没有，Nginx 需开启 range 模块；CDN 需配置透传 Range 请求头
修复 MP4 封装：
ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4
注意：这个操作必须在上传前完成，CDN 缓存后无法动态修正。
投屏不是前端能“防”或“开”的开关，它是个资源就绪 + 协议兼容 + 设备支持的综合结果。最常被忽略的一点是：你写的“防投屏”JS，往往才是让投屏失败的真正原因。
