disableRemotePlayback不能当防投屏开关用，因其仅为向浏览器发出禁用远程播放的提示信号，非强制策略；Chrome/Edge仅隐藏UI图标，Safari自iOS 15.4起部分支持，Firefox完全忽略，且无法防御系统录屏、手机拍摄或抓包下载。
HTML 视频防投屏没有“开关式”方案，disableRemotePlayback 只是提示，不能替代 DRM 和服务端策略。
为什么 disableRemotePlayback 不能当防投屏开关用
这个属性只是向浏览器发一个“别让我投屏”的信号，不是强制指令。Chrome/Edge 会隐藏投屏图标，但用户仍可手动打开系统级 AirPlay 或 Chromecast 窗口；Safari 自 iOS 15.4 起才支持该提示，且仅对 AirPlay 有效；Firefox 完全忽略它。更关键的是：它对系统录屏、手机拍摄、抓包下载视频 URL 零防护力。
-
disableRemotePlayback="true"或disableRemotePlayback="disabled"是错误写法，浏览器直接无视 - 必须写成布尔属性形式：
<video controls disableremoteplayback></video> - 动态 JS 设置（如
video.disableRemotePlayback = true）在部分浏览器中不生效，建议初始化时声明
controlslist="noremoteplayback" 和 disableRemotePlayback 的关系
两者目标一致，但机制不同：controlslist 是控制 UI 层面的按钮可见性，属于“藏按钮”；disableRemotePlayback 是向播放引擎传递策略信号，属于“提请求”。实际项目中建议同时使用：
<video controls controlslist="noremoteplayback nodownload nofullscreen" disableRemotePlayback> <source src="video.mp4" type="video/mp4"> </video>
-
controlslist兼容性略好（Chrome 78+、Edge 79+、Safari 15.4+），但仅影响右键菜单和地址栏图标，不影响快捷键（如 macOS Cmd+Shift+5 启动录屏） - 两者叠加使用可覆盖更多触发路径，但依然不构成版权保护闭环
真正起作用的版权保护必须组合服务端与前端
防投屏只是表象，核心是防止未授权解密和播放。EME（Encrypted Media Extensions）才是关键链路，但它本身不加密、不解密、不发密钥——只负责调度 CDM（Content Decryption Module）。
立即学习“前端免费学习笔记（深入）”；
- 视频文件必须提前用
shaka-packager等工具加密，并嵌入 PSSH box（Widevine/PlayReady 初始化数据） - 前端调用
navigator.requestMediaKeySystemAccess检测 DRM 支持，再绑定mediaKeys到<video></video> - 许可证服务器（License Server）必须校验 JWT Token、设备 ID、订阅状态等，才能返回可用 license
- 所有 EME 操作强制 HTTPS，HTTP 页面下 API 直接不可用；FairPlay 还额外要求可信 TLS 证书
容易被忽略的硬伤点
很多团队卡在“视频能播但没 DRM 效果”，往往是因为这几个细节没对上：
- MP4 文件没带
cenc初始化类型，或 DASH 清单（.mpd）里ContentProtection元素缺失或 schemeIdUri 错误 - 许可证响应格式不匹配：Widevine 要 JWPL 二进制 blob，PlayReady 要 XML，返回错一种就解密失败
- CDN 缓存了未加密的 manifest 或 init segment，导致 EME 加载到明文头信息后放弃走 DRM 流程
- 测试时用了 localhost，上线却忘了切 HTTPS，EME API 在非安全上下文中静默失效
投屏控制不是前端单点能解决的事，它横跨浏览器策略、CDN 配置、DRM 打包、许可证鉴权四个层面。漏掉任意一环，disableRemotePlayback 就只剩一个好看的属性名。
