disableRemotePlayback是HTML5 video唯一原生防投屏提示属性，仅向Chrome/Edge发出禁用信号（UI置灰），Safari部分支持、Firefox完全忽略，且无法阻止系统录屏或物理盗录。
disableRemotePlayback 仍是当前唯一原生支持的防投屏提示属性，但别指望它能“防住”——它只影响 Chrome/Edge 的投屏 UI 显示，对 Safari（仅部分支持）、Firefox（完全不支持）和所有系统级录屏无效。
为什么 disableRemotePlayback 经常失效
这个属性不是开关，而是“礼貌请求”。浏览器实现差异极大：
- Chrome/Edge：设为
disableRemotePlayback（无值）后，地址栏 Cast 图标变灰，右键菜单移除“投射到设备”项；但用户仍可手动点 Cast 按钮投整个标签页 - Safari：iOS 15.4+ 和 macOS 12.3+ 仅对 AirPlay 菜单做弱提示，且不阻止 AirPlay 镜像模式
- Firefox：该属性被完全忽略，
video.disableRemotePlayback在 about:config 中也无对应开关 - Android WebView / 微信内置浏览器：多数版本直接无视，部分定制内核甚至会强制启用投屏入口
更关键的是：它对 screen capture、QuickTime 录屏、手机拍摄投屏画面等行为零约束。
前端监听投屏行为比禁用更实际
与其试图“堵”，不如“察”。真正能落地的防御动作是捕获投屏相关事件并响应：
立即学习“前端免费学习笔记（深入）”；
-
webkitbeginfullscreen（Safari/iOS）或enterpictureinpicture（Chrome）触发时，可pause()视频 + 弹出遮罩层 + 上报埋点 - 监听
document.visibilityState === 'hidden'并结合screen.orientation变化，辅助判断是否进入投屏镜像状态 - 注意：
webkitendfullscreen不可靠，部分安卓 WebView 根本不触发；建议用setTimeout延迟恢复播放，避免误判
这类监听不能阻止投屏，但能显著增加盗录成本——比如让投屏画面突然黑屏或弹出水印警告。
服务端配合才是防投屏的核心防线
前端属性和事件监听只是表层，真正起效的必须是服务端策略：
- 视频分片 URL 必须带一次性 Token（如 JWT），有效期 ≤ 30 秒，且绑定
User-Agent+IP+Referer - HLS/DASH 清单（
.m3u8/.mpd）禁止缓存（Cache-Control: no-store），防止被静态抓取 - DRM license server 配置
outputProtection策略，要求 HDCP 1.4+ 输出（对 Chromecast/AirPlay 设备生效，但对录屏无效） - 对敏感时段（如视频最后 5 秒）动态返回空片段或加密错误码，打断广告拼接类投屏源
单独靠 HTML 属性防投屏，就像用纸糊门防盗——看起来有动作，但门根本没锁。真正要拦住的不是浏览器，而是那个在控制台里复制 network 请求的人。
