HTML视频元素无法真正阻止投屏，disableRemotePlayback仅隐藏UI按钮但可被绕过，唯一有效方案是通过EME接入Widevine/FairPlay等DRM系统实现输出保护。
HTML视频元素本身无法阻止投屏
浏览器的 <video></video> 标签没有原生权限控制机制来禁用投屏——投屏（如 Chrome 的 Cast、macOS 的 AirPlay、Windows 的“连接到无线显示器”）发生在系统/浏览器底层，HTML 和 JavaScript 无权干预。所谓“防投屏”，实际是限制内容在投屏设备上正常解码或显示，而非阻断投屏动作本身。
canplaythrough 事件 + disableRemotePlayback 属性可抑制部分投屏入口
disableRemotePlayback 是 HTMLMediaElement 的布尔属性，作用是隐藏浏览器 UI 中的投屏按钮（如 Chrome 地址栏右侧的 Cast 图标），但不阻止快捷键（Ctrl+Shift+M）或系统级投屏。需注意：
- 仅对
<video></video>和<audio></audio>元素生效，且必须在加载早期设置（最好写在 HTML 标签里） - 部分浏览器（如 Safari）不支持该属性，iOS 上完全无效
- 设置后仍可能被开发者工具手动移除属性绕过
示例写法：
<video disableRemotePlayback controls><source src="video.mp4" type="video/mp4"></video>
DRM 加密是真正可行的防投屏方案
只有通过 EME（Encrypted Media Extensions）接入商业 DRM 系统（如 Widevine、FairPlay、PlayReady），才能让播放器在检测到非可信输出（例如未签名的投屏会话、不安全的 HDMI 链路）时主动拒绝解密或黑屏。关键点：
立即学习“前端免费学习笔记（深入）”；
- DRM 不是前端代码能“打开开关”实现的，需服务端打包加密（如用
shaka-packager）、CDN 支持许可证分发、前端集成对应 CDM - 投屏是否被拦截，取决于 DRM 策略配置中的
outputProtection（如hdcpRequired）和终端设备能力 - 普通 MP4 直链 + 前端 JS 完全无法触发 DRM 流程；未启用 EME 的页面哪怕加了
disableRemotePlayback，投屏后照样播
常见误操作：监听 screen.orientation 或 visibilitychange 并 pause
有人试图用 screen.orientation 变化或 document.hidden 判断投屏发生，这是无效的。投屏启动时这些 API 不触发变化；即使页面切到后台，投屏依然持续传输原始流。更糟的是，这类逻辑容易引发误暂停（比如用户切 Tab、锁屏），反而损害正常体验。
真正需要关注的，是 DRM 许可证请求失败时的降级处理——比如 mediaKeys.setServerCertificate 拒绝、keystatuschange 中出现 "status-change: output-down"，这时才应提示“当前环境不支持播放”并停播。
防投屏不是加一行属性或一段 JS 就能解决的事，它本质是内容提供商与终端厂商、浏览器、DRM 服务商之间的一整套信任链协作。没接入 Widevine/FairPlay，其他所有前端手段都只是障眼法。
