disableRemotePlayback 仅是提示而非拦截，controlslist="noremoteplayback" 更可靠地隐藏UI投屏按钮，但真正防投屏需服务端鉴权、DRM加密、输出保护及环境检测等组合方案。
disableRemotePlayback 属性只是提示，不是拦截
HTML5 video 标签的 disableRemotePlayback 是目前唯一原生支持的“防投屏”声明，但它不强制阻止，只向浏览器发出“不希望投屏”的信号。Chrome/Edge 会据此隐藏地址栏 Cast 图标和右键菜单中的投屏项；Safari 自 iOS 15.4 起对 AirPlay 有类似响应；Firefox 完全忽略该属性。写法必须是 disableRemotePlayback（无等号、无引号、无值），disableRemotePlayback="true" 会被浏览器当作无效字符串忽略。
controlslist="noremoteplayback" 才是 UI 层面的统一开关
相比孤立的 disableRemotePlayback，controlslist 是更实用的组合控制方案，它直接作用于播放器控件栏：
-
controlslist="noremoteplayback"：在 Chrome/Edge/Safari（部分版本）中隐藏投屏按钮，比单独用disableRemotePlayback更可靠 -
controlslist="noremoteplayback nodownload nofullscreen"：一并禁用下载、全屏、投屏三个高风险操作入口 - 注意：该属性仅影响控件 UI，不阻止用户手动打开浏览器 Cast 功能投整个标签页或桌面
真正防投屏得靠服务端+DRM+输出策略
前端任何 HTML 属性都无法防止系统级录屏、手机拍摄、抓包下载 URL 或投整个页面。若业务真有强保护需求（如金融培训、版权内容），必须组合以下技术：
- 服务端动态鉴权：每个视频分片请求需校验 JWT Token，绑定设备指纹、IP、时效（例如 10 分钟过期）
- HLS/DASH 加密分片：用 AES-128 或 CENC 对
.ts/.mp4片段加密，密钥由授权服务按需下发 - DRM 输出保护：Widevine（Chrome/Android）、FairPlay（Safari/iOS）可配置
outputProtection策略，要求 HDCP 连接，禁用不安全输出（如非加密 HDMI） - 前端环境检测：监听
enterpictureinpicture、webkitbeginfullscreen等事件，触发告警或暂停；检查document.hidden和调试工具痕迹
别忽略物理层和网络层的失效点
很多团队在加完 disableRemotePlayback 和 controlslist 后就以为“防住了”，结果上线后仍被批量盗录。关键盲区包括：
立即学习“前端免费学习笔记（深入）”；
- HTTPS 缺失：Cast SDK、DRM License 请求、HLS m3u8 地址都强制要求 HTTPS，HTTP 下静默失败且无报错
- 内网地址不可投：Chrome Cast API 拒绝播放
localhost或私有 IP 的视频 URL，必须走公网域名或反向代理 - 电视端兼容断层：智能电视浏览器普遍不支持 MSE，HLS 地址直连可能黑屏；WebRTC 方案又受限于 NAT/UDP 阻断
- 水印缺失：没在视频流中嵌入不可移除的半透明文字水印，也没在前端 Canvas 叠加动态用户 ID/时间戳，溯源能力归零
