video元素无法原生控制播放会话数或防投屏，因投屏由用户主动触发且属平台级权限；有效策略是服务端用一次性token限制流复用，并配合MediaSource动态中断与前端error监听实现协同防护。
video 元素本身不提供「播放会话数量」或「防投屏」的原生控制能力。浏览器对投屏（如 Chrome 的 Cast、Safari 的 AirPlay）的触发完全由用户主动发起，HTML 属性或 JS API 无法拦截、禁止或计数投屏行为——这是平台级权限，Web 标准刻意未开放干预接口。
真正能做的，是通过组合策略限制「被投屏后仍可继续播放」的场景，核心思路是：**让投屏端无法获得有效音视频流，或使投屏内容失效**。
为什么 controls 和 autoplay 对防投屏无效
这两个属性只影响页面内控件显示和自动播放策略，与投屏通道无关。用户点击右上角 Cast 图标时，浏览器直接将当前 video 元素的解码输出镜像推送到接收端，不经过 JS 层，也无法用 removeAttribute('controls') 或禁用 play() 来阻断。
用 MediaSource + URL.createObjectURL() 动态喂流时如何削弱投屏可用性
- 投屏依赖浏览器对媒体源的“可读取性”。若你使用
MediaSource并在sourceopen后动态 appendArrayBuffer，且每次 append 前检查mediaElement.src是否已被 Cast 检测到（可通过document.visibilityState === 'hidden'+mediaElement.paused组合粗略推测），可主动mediaSource.endOfStream()并revokeObjectURL() - 但注意：此法无法阻止投屏发起，仅能在检测到页面失焦+视频暂停后快速切断流，使已开始的投屏黑屏或中断
- 部分安卓 Chrome 在投屏中会缓存最近 1–2 秒帧，所以需配合
mediaElement.currentTime = mediaElement.duration+pause()强制清空播放位置
服务端配合：用一次性 token 限制播放会话生命周期
这是最可靠的一环——防投屏本质是防「同一份流被多端复用」：
- 每个
video的src必须带短期有效 token，例如https://cdn.example.com/vid.mp4?token=abc123&expires=1635724800 - 服务端验证 token 时，同时校验该 token 是否已被用于其他设备（如记录
session_id或设备指纹哈希） - 当检测到重复使用（比如投屏端和手机端同时请求同一 token），服务端返回
403或空响应，使投屏端加载失败 - 前端需监听
error事件并 fallback 提示：video.addEventListener('error', () => { console.warn('播放会话已被其他设备占用'); })
容易被忽略的关键点
投屏不是“复制 HTML”，而是复制当前 HTMLMediaElement 的解码状态。这意味着：即使你用 JS 清空 src 或调用 load()，只要投屏会话未关闭，接收端仍可能持续渲染最后一帧——必须靠服务端 token 失效或流中断才能真正终止。单纯前端防护只能增加投屏成本，无法根除。
