html视频元素无法真正阻止投屏，controlslist="noremoteplayback"仅隐藏投屏按钮，用户仍可通过系统快捷键、浏览器菜单或第三方工具投屏，ios/ipados完全忽略该属性，当前无可靠api检测或禁用投屏。
HTML视频元素本身无法阻止投屏
浏览器没有提供任何标准 API 让网页主动禁用投屏（如 Chrome 的 Cast、Windows 的“连接到无线显示器”、macOS 的 AirPlay）。video 标签的 disablePictureInPicture、controlsList="nodownload noremoteplayback" 等属性，仅影响本地播放控件行为，对系统级投屏通道完全无效。
所谓“防投屏”，实际是试图干扰投屏设备从浏览器中捕获画面的能力，但这个过程发生在操作系统或硬件层，网页 JS 和 HTML 无权干预。
noremoteplayback 只能隐藏投屏按钮，不阻止投屏操作
在 <video></video> 上设置 controlsList="noremoteplayback"，仅会隐藏右键菜单和控制栏里的投屏图标（如 Chrome 的 Cast 按钮），但用户仍可通过以下方式正常投屏：
- 按系统快捷键（如 Win+K、macOS 的菜单栏 AirPlay 图标）
- 打开 Chrome 地址栏右侧的三点菜单 → “投射”
- 使用第三方投屏工具（如 OBS 虚拟摄像头、Scrcpy、AirServer）直接抓取窗口或屏幕
该属性在 Safari 和部分 Android 浏览器中支持度差，且 iOS/iPadOS 完全忽略 noremoteplayback —— AirPlay 按钮照常出现并可用。
尝试监听投屏状态？目前没有可靠方案
虽然 Chrome 曾实验性支持 document.onwebkitvisibilitychange 或 screen.orientation 变化来间接推测投屏动作，但这些信号与投屏无必然因果关系：
- 用户切到其他标签页也会触发
visibilitychange - 横竖屏旋转、分屏、PWA 安装等都会改变
screen.orientation - 现代浏览器已移除
webkitRemotePlaybackAPI（曾用于检测 AirPlay 状态），当前无标准替代接口
试图用 getVideoPlaybackQuality() 或 canvas 帧采样做实时内容比对，既消耗性能，又极易被绕过（如投屏时关闭网页、用录屏软件替代投屏）。
真正可控的边界只在 DRM 和播放环境
如果业务强依赖防投屏，唯一可行路径是放弃纯 HTML 方案，转向受控播放环境：
- 接入
EME（Encrypted Media Extensions），配合商业 DRM 服务（如 Google Widevine、Apple FairPlay）—— 投屏设备需同时支持对应 DRM 才能解密播放，多数消费级投屏设备不满足条件 - 使用原生 App（iOS/Android）封装 Webview，并启用平台级限制（如 iOS 的
AVPlayerViewController.allowsExternalPlayback = NO） - 企业内网场景可部署终端管控策略（如禁用 Windows 投屏服务、组策略屏蔽 Chrome Cast 功能）
纯前端 HTML + JS 实现“防投屏”，本质是伪命题。所有号称“一行代码禁投屏”的方案，要么混淆了 UI 隐藏与功能禁用，要么依赖早已废弃或未标准化的私有 API。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
