disableRemotePlayback 属性仅是提示而非阻断机制，浏览器可忽略，系统级投屏（如AirPlay、Chromecast）完全绕过HTML控制；真正有效的防护需在网络与设备层切断发现机制，并配合服务端签名URL、动态密钥等措施。
disableRemotePlayback 属性只能提示，不能阻断
disableRemotePlayback 是 HTML5
投屏根本不在 HTML5 控制范围内
用户点手机优酷 App 的 TV 图标、用 macOS 系统菜单“镜像到 Apple TV”、或浏览器右上角 Cast 按钮投整个标签页——这些行为全部绕过 <video> 标签。网页里删掉 video 元素、禁用 MediaSource API、甚至关掉 JavaScript，都不影响 App 或系统协议把视频流推过去。所谓“HTML 阻断投屏”，本质是混淆了播放容器（video）和传输通道（DLNA/AirPlay/WebRTC）的边界。
真正能干预投屏的只有网络与设备层
想让电视“搜不到”或“连不上”，必须在物理或网络层面切断发现机制：
- 路由器开启访客网络并启用客户端隔离，让手机和电视不在同一广播域
- 电视改用有线连接，且该网段不广播 SSID、不开放 UPnP/DLNA 服务
- 关闭电视系统设置里的“快速分享”“多屏互动”“AirPlay 接收”等选项（路径因品牌而异，通常在【网络】或【通用】→【投屏】）
- 在防火墙规则中屏蔽 SSDP（UDP 1900）、AirPlay（TCP 7000）、Chromecast（TCP 8008/8009）等端口
前端能做的只是配合服务端降低盗链风险
防投屏 ≠ 防盗看。如果你担心的是视频被录屏或 URL 被扒走，重点应放在服务端控制：
立即学习“前端免费学习笔记（深入）”；
- 所有
video.src必须由后端生成带签名、有时效（如 300 秒）、绑定用户 UA/IP 的临时地址，例如/proxy/v/abc123?t=1734618000&s=7a2f9e4c&u=uid_8823 - 对 HLS/DASH 流启用动态分片密钥，避免 .m3u8 文件暴露完整 ts 列表
- 在播放关键帧前校验前端是否处于可信上下文（如监听
webkitbeginfullscreen后立即暂停并弹窗警告） - 明确放弃“禁右键”“禁 F12”等前端 JS 小动作——它们对真实盗录毫无意义
浏览器没有提供阻断投屏信号的 API，任何试图用 HTML 或 JS “截断”投屏握手过程的方案，都会在 Chrome 扩展未安装、iOS 系统级镜像或 Android 投屏 SDK 调用时彻底失效。
