防投屏卡顿需综合策略：浏览器投屏时强制软解、禁用GPU加速，故须设preload="metadata"、限制H.264 Level≤3.1、禁用MSE、优先webm/VP9、CDN支持206分片。
防投屏卡顿不是加个属性就能解决的问题——它本质是浏览器在检测到投屏意图时，主动降频解码、禁用硬件加速、甚至切换渲染路径导致的性能断层。你看到的“一投就卡”，90% 情况下和视频本身无关，而是投屏握手阶段触发了浏览器的保守策略。
为什么投屏后 video 突然卡顿？
Chrome / Safari / Edge 在发起 cast 或 presentation 会话时，会强制将当前 <video> 切换到软件解码路径，并关闭 GPU 合成层。这不是 bug，是安全与功耗策略：防止高帧率/高分辨率内容被未授权设备截获或过热。典型现象包括：
- 投屏瞬间出现 1–2 秒黑屏或花屏
- 原本流畅的 60fps 视频掉到 24fps，拖动进度条明显延迟
-
chrome://histograms/Video中可见VideoDecoderSoftwareFallback计数飙升 - iOS Safari 投屏时直接 fallback 到
AVPlayerLayer，绕过 WebKit 视频管线
preload="metadata" + IntersectionObserver 是基础防线
投屏卡顿往往从“加载混乱”开始。多个视频同时触发完整加载，会挤占投屏协商所需的 IPC 通道和解码器资源。必须切断这个源头：
- 所有
<video>统一设preload="metadata"，禁止自动拉取主体数据 - 非首屏视频保持
src=""，用IntersectionObserver监听进入视口后再赋值src - 已进入视口但尚未投屏的视频，调用
.load()前先检查navigator.canShare或监听document.addEventListener('visibilitychange')，避免在投屏准备期触发加载 - 慎用
autoplay：投屏场景下用户手势不可靠，autoplay muted在 Chrome 120+ 已被限制为仅允许在页面激活后 500ms 内触发
H.264 Level ≤ 3.1 + faststart 是硬解兼容底线
投屏设备（尤其是 Chromecast Gen 3、Apple TV 4K）的解码芯片不支持 High@4.0 及以上 profile。一旦源视频编码越界，浏览器会在投屏握手时静默 fallback 到软解，CPU 占用瞬间拉满：
立即学习“前端免费学习笔记（深入）”；
- 用
ffprobe -v quiet -show_entries stream=profile,level -of csv your.mp4检查 profile 和 level - 重编码必须加
-profile:v baseline -level 3.1（非main或high） - MP4 必须带
-movflags +faststart，否则投屏端无法在 moov 头未到达前开始解码 - 优先提供
video/webm备用源：<source src="vid.webm" type="video/webm">，VP9 在投屏链路中硬解支持更稳
投屏中禁用 MSE，改用原生 src 切换
很多团队试图用 MediaSource Extensions（MSE）做自适应码率来“应对投屏带宽波动”，结果适得其反。MSE 在投屏会话中会触发额外的 buffer 管理开销，且 sourceBuffer.appendBuffer() 调用极易被中断：
- 检测到
document.visibilityState === 'prerender'或window.matchMedia('(display-mode: standalone)').matches时，立即销毁MediaSource实例 - 投屏状态下，全部切回
<video src="xxx.mp4">模式，靠服务端 Range 支持实现边下边播 - CDN 必须返回
206 Partial Content，且响应头含Accept-Ranges: bytes，否则投屏端会整包重试 - 移动端投屏务必加
playsinline webkit-playsinline muted autoplay，缺任意一个都可能导致 Safari 投屏失败后 fallback 到全屏黑屏
真正难处理的是多视频页投屏时的解码器争抢——浏览器不会帮你排队，它只会让第一个拿到解码器的 video 先跑，其余全卡在 waiting 状态。这时候得靠服务端切片 + 客户端状态同步，而不是前端单点优化。
