纯HTML无法防投屏，disableRemotePlayback仅隐藏UI入口；真正有效需服务端校验Referer/Origin、一次性签名token及动态响应头，并对投屏UA返回错误或降质内容。
纯 HTML 无法在后台实现防投屏，disableRemotePlayback 只是前端提示，真正起作用的必须是服务端策略组合——否则用户点一下浏览器右上角 Cast 图标，你的视频就已投出去了。
为什么 disableRemotePlayback 单独用没用
这个属性只是告诉浏览器“请不要显示投屏入口”，但：
• Chrome/Edge 中它只隐藏地址栏 Cast 按钮和右键菜单里的“投射到设备”，不阻止用户手动打开 Cast 面板并选择当前标签页
• Safari 对 disableRemotePlayback 的支持从 iOS 15.4 才开始，且仅影响 AirPlay 菜单，对系统级镜像（如 macOS 屏幕镜像）完全无效
• Firefox 完全忽略该属性，设了等于没设
• 用户禁用 JS 后，所有基于属性的 UI 控制都会失效
后端必须校验的三个关键上下文
要让投屏行为实际受控，服务端需在每次视频资源请求时验证以下三项，缺一不可：
-
Referer + Origin 绑定：Nginx 或 CloudFront 规则中严格限制
$http_referer必须匹配你主站域名（如^https://your-app\.com），同时校验Origin头非空且合法 -
一次性播放 Token：前端请求视频前先调
/api/play?videoId=abc，后端生成带签名、时效（建议 ≤ 90 秒）、绑定userId和userAgentHash的 token，返回给前端用于拼接代理 URL -
动态响应头控制：代理流返回时，必须设置
Content-Disposition: inline（禁用下载式响应）、X-Content-Type-Options: nosniff，并拒绝带Range请求头但无有效 token 的分片请求
如何让投屏内容“播不了”而非“看不见按钮”
即使用户强行投屏成功，也要确保投出去的是空白、错误或降质内容：
立即学习“前端免费学习笔记（深入）”；
- 在代理接口中检测
User-Agent是否含CrKey（Chromecast）、AppleCoreMedia（AirPlay）等特征，命中则返回 403 或伪造的 1px 黑帧 MP4 - 对 HLS 流，服务端动态改写
.m3u8：移除高码率变体、插入加密#EXT-X-KEY（哪怕用 Clear Key），让投屏端因解密失败而黑屏 - 若用 DASH，可在
MPD中设置minBufferTime为超大值（如 60s），或注入无效SegmentTemplate，使投屏端解析失败
最易被忽略的一点：投屏本质是另一个设备发起的 HTTP 请求，它不会携带你网页的 Cookie 或 localStorage。所以所有鉴权逻辑必须落在 URL 参数或请求头里——而且不能只靠前端拼，得由后端签发并校验，否则 token 就是明文摆在那里让人复制。
