disableRemotePlayback属性必须以布尔形式直接写在video标签中才生效，如<video controls disableRemotePlayback>；赋值写法（如="true"）或JS动态设置均无效，且仅Chrome/Edge和iOS 15.4+ Safari支持，Firefox及多数WebView不识别。
disableRemotePlayback 属性怎么写才生效
HTML5 video 标签没有“强制防投屏”能力，disableRemotePlayback 是唯一原生支持的提示性属性，但它只起建议作用，不是策略开关。写法必须严格：直接作为布尔属性出现在标签中，不带等号、不赋值。
✅ 正确：<video controls disableRemotePlayback></video>
❌ 错误：disableRemotePlayback="true"、disableRemotePlayback="disabled"、video.setAttribute('disableRemotePlayback', 'true') —— 这些都会被浏览器忽略。
该属性仅影响 Chrome/Edge（Chromium 内核）和 Safari（iOS 15.4+/macOS 12.3+）的 UI 入口：隐藏右键菜单里的“投屏”项、置灰地址栏 Cast 图标。Firefox 完全不识别，Android WebView 和小程序环境行为不可靠。
立即学习“前端免费学习笔记（深入）”；
为什么 disableRemotePlayback 拦不住实际投屏
它不改变视频流本身，也不干预系统级协议。以下行为完全不受影响：
- 用户手动启用 AirPlay / Chromecast / Miracast 系统镜像（整屏推流）
- 用手机拍摄电视画面（物理盗录）
- 通过开发者工具 Network 面板抓取
.mp4、.m3u8或分片 URL 后本地下载 - 调用
video.requestPictureInPicture()或快捷键触发画中画（注意：这和投屏是不同机制，但常被混淆）
关键点：该属性只是向浏览器“说一句”，浏览器听不听、平台支不支持、用户绕不绕开，都不在它的控制范围内。
真正降低投屏风险的组合手段
如果业务对投屏敏感（如内训视频、试看片段），需放弃“前端一刀切”幻想，转向前后端协同：
- 服务端生成带时效、绑定用户/设备/IP 的动态 Token，URL 形如
/stream?vid=abc&token=xyz&ts=1718123456，过期即 403 - 前端监听
webkitbeginfullscreen（Safari）或enterpictureinpicture（Chrome），触发时暂停播放并弹出提示：“检测到全屏行为，已暂停” - 对高价值内容启用 DRM（如 Widevine），并在 license server 中配置
outputProtection要求 HDCP，可阻止非认证输出设备解密播放 - 避免使用纯 MP4 直链，改用 HLS + AES-128 加密，密钥由后端按需下发，不硬编码在 JS 或 HTML 中
注意：动态 JS 设置 video.disableRemotePlayback = true 在多数浏览器中无效，必须初始化时声明。
最容易被忽略的兼容性陷阱
很多团队测试只跑 Chrome，上线后 iOS 用户仍能 AirPlay 成功——因为 Safari 对 disableRemotePlayback 的支持从 iOS 15.4 才开始，且仅限 AirPlay，对 DLNA/Miracast 无影响。更麻烦的是，微信 Android（X5 内核）、QQ 浏览器等环境会完全忽略该属性，甚至不渲染对应 UI。
如果你的页面需要覆盖企业内网 iPad（运行 iOS 14.x 或更早），这个属性等于不存在。此时唯一可控的防线只剩服务端鉴权 + 动态令牌 + DRM 输出策略。
