EME接口本身不防投屏，仅负责解密；真正限制投屏需依赖DRM许可证策略（如HDCP要求）与disableRemotePlayback布尔属性协同，但仅能降低普通用户误操作概率，无法阻止录屏、抓包或标签页投射等主动盗录行为。
EME 接口本身不防投屏，它只管解密——想靠 navigator.requestMediaKeySystemAccess 或 mediaKeySession.update() 直接阻止 Chromecast 或 AirPlay，行不通。
disableRemotePlayback 属性是唯一原生提示位，但仅限“提示”
该属性向浏览器声明“不希望此视频被远程播放”，但不是指令。Chrome/Edge 会隐藏地址栏 Cast 图标、禁用右键菜单中的投屏项；Safari 自 iOS 15.4 起对 AirPlay 有类似响应；Firefox 完全忽略。
-
disableRemotePlayback必须写成布尔属性形式：<video disableremoteplayback></video>，写成disableRemotePlayback="true"会被浏览器当成字符串值，直接失效 - 动态设置（如
video.disableRemotePlayback = true）在部分 Chrome 版本中不生效，建议初始化时就写死在 HTML 中 - 它对系统级录屏（macOS QuickTime、Windows Xbox Game Bar）、手机拍摄投屏画面、抓包下载分片完全无效
真正影响投屏行为的是 DRM 许可证策略，不是前端 JS
EME 的价值在于把播放控制权交还给服务端：许可证服务器返回的 license 响应里，可以嵌入输出保护要求（output protection），例如：
- Widevine license 中设置
required_output_protection为HDCP，CDM 会拒绝在不支持 HDCP 的输出路径（如部分 Miracast 设备或老旧 HDMI 链路）上解密 - FairPlay 通过
contentKey的outputProtection字段限制 AirPlay 输出类型（如禁止镜像、仅允许加密流） - 这些策略只有在视频已加密、且 CDM 实际参与解密时才起效；未加密视频即使设了
disableRemotePlayback，照样能被整个标签页投出去
EME + disableRemotePlayback 组合的实际防护边界
两者叠加只能做到一件事：降低普通用户“顺手一点就投出去”的概率。它无法对抗有意识的盗录行为，因为投屏与否最终由操作系统和硬件链路决定，前端无权干预。
立即学习“前端免费学习笔记（深入）”；
- Chrome 投整个标签页（Cast Tab）不受
disableRemotePlayback影响，也不走 EME 解密流程 - 用户打开开发者工具 → Network 面板 → 找到
.mpd或.m3u8→ 复制 URL 到 VLC，照样能播、能录、能转存 - 若服务端没做 Token 鉴权、Referer 校验、IP 绑定或分片 URL 签名，EME 再完整也拦不住盗链
最易被忽略的一点：EME 初始化失败时，video 元素会退回到明文播放逻辑，此时 disableRemotePlayback 仍存在，但 DRM 策略已失效——你得监听 encrypted 和 error 事件，主动 fallback 或报错，否则用户根本不知道正在播的是未受保护的内容。
