disableRemotePlayback仅是浏览器可忽略的UI提示，Chrome/Edge中稳定生效，Safari部分支持，Firefox完全无视；它无法阻止标签页投屏、屏幕镜像或第三方推流，真正防护需依赖服务端鉴权、分片加密与动态Token。
disableRemotePlayback 不是密码，也不是加密开关，它只是一个浏览器可忽略的提示信号。加了它，不等于防住了投屏；没加，也不代表一定被投——效果完全取决于浏览器是否买账。
disableRemotePlayback 属性到底管不管用
这个属性只在 Chrome / Edge（Chromium 内核）中稳定生效：视频右键菜单里“投屏”选项会变灰，地址栏 Cast 图标消失；Safari 自 iOS 15.4 起支持 AirPlay 禁用提示，但行为不稳定；Firefox 完全无视，设成 true 或 disabled 都无效。
关键点在于：disableRemotePlayback 必须写成布尔属性形式，不能赋值：
<video controls disableRemotePlayback> <source src="video.mp4" type="video/mp4"> </video>
-
disableRemotePlayback="true"→ 浏览器当普通字符串属性处理，直接忽略 -
disableRemotePlayback=""→ 部分旧版 Safari 可能误判为 false - 动态 JS 设置（如
video.disableRemotePlayback = true）→ 多数浏览器不响应，初始化时声明才可靠
为什么它防不住真正的投屏行为
它不干预网络层、不解密内容、不控制输出设备，只是 UI 层面的“礼貌请求”。以下行为它完全无法阻止：
- 用户手动打开 Chrome 的 Cast 按钮，选择“投整个标签页”或“投桌面”
- 手机开启屏幕镜像（iOS 屏幕镜像、Android 无线显示），把整个浏览器窗口推过去
- 用第三方工具（如 OBS、Scrcpy）捕获浏览器窗口并推流到电视
- 抓包拿到
.m3u8地址后，用 VLC 或 ffplay 直接拉流播放
换句话说：disableRemotePlayback 对抗的是“顺手一点投屏”的用户，不是对抗有明确目标的截取行为。
立即学习“前端免费学习笔记（深入）”；
真正影响投屏风险的是服务端和协议层
前端加属性只是表象，实际防护能力来自后端与传输设计：
- 使用 HLS/DASH + AES-128 加密，密钥由鉴权接口动态下发，避免明文密钥泄露
- 视频 URL 带短时效 Token（如 5 分钟），且绑定用户 ID、IP 或设备指纹，过期即失效
- 代理服务（而非 302 重定向）中转 S3 请求，彻底隐藏原始对象路径，防止 URL 被复用
- 对 DRM 内容启用
outputProtection策略（如 Widevine 要求 HDCP），限制非安全输出路径
这些措施下，即使用户绕过 disableRemotePlayback 成功投屏，拿到的也只是加密分片或已过期链接，无法解出画面。
容易被忽略的物理与系统级风险
所有 HTML5 层面的控制，包括 disableRemotePlayback 和 disablePictureInPicture，都默认假设用户操作发生在浏览器内。但现实更复杂：
- macOS QuickTime、Windows Xbox Game Bar 这类系统级录屏工具，完全绕过网页权限模型
- 用户用另一台手机拍摄电视屏幕——这种物理盗录，任何前端代码都无能为力
- 开发者工具 Network 面板里找
media类型请求，复制 URL 下载分片——只要没做分片加密或 Token 校验，就必然成功
所以，真正需要投入精力的地方，从来不在 <video> 标签上写了几个布尔属性，而在于服务端有没有做动态鉴权、CDN 是否配置了严格 CORS、HLS 密钥是否每次播放都刷新。
