disableRemotePlayback是HTML5 video标签唯一原生支持的禁用远程投屏提示属性，仅向浏览器发出“不希望投屏”信号，非强制策略；必须写成无值布尔形式（disableRemotePlayback），赋值如"true"会被忽略；controlslist="noremoteplayback"兼容性更广，但均无法阻止已建立投屏或系统级镜像。
HTML 视频加 disableRemotePlayback 属性，只是向浏览器发一个“请勿投屏”的提示信号，不是强制开关，也不能阻止已建立的投屏会话。
为什么 disableRemotePlayback="true" 不生效
这是最常踩的坑：该属性必须写成无值布尔形式，即 disableRemotePlayback，不能赋值。浏览器（尤其是 Safari 和 Chrome）会直接忽略 disableRemotePlayback="true"、disableRemotePlayback="disabled" 甚至 disableRemotePlayback="1" 这类写法。动态设置（如 videoEl.setAttribute('disableRemotePlayback', '')）在部分 Android WebView 和旧版 Safari 中也大概率失效——建议初始化时就在 HTML 标签里声明。
controlslist="noremoteplayback" 是更广谱的兼容方案
它比 disableRemotePlayback 更早被支持，Chrome、Edge、较新 Safari 都识别，语义也更明确：禁用远程播放入口（包括右键菜单、地址栏 Cast 图标等）。可与 disableRemotePlayback 共存，互不冲突。
- 写法必须是
controlslist="nodownload noremoteplayback"，多个指令用空格分隔，noremoteplayback不带引号、不赋值 - 它只隐藏 UI 上的投屏触发点，不影响用户已点击 Cast 后继续投屏的行为
- 在微信内置浏览器、QQ 浏览器（X5 内核）中大概率被忽略，需额外判断 UA 并降级提示
弹窗警告只能做兜底感知，不能拦截投屏动作
前端无法阻止投屏协议协商，但可通过监听关键事件感知异常行为并干预：
-
webkitbeginfullscreen：Safari/Chrome 全屏前触发，可在此暂停视频或弹窗提示 -
enterpictureinpicture：进入画中画时触发，调用video.pause()+alert()是常见做法，但注意 iOS 15+ 要求用户手势上下文才允许play() -
visibilitychange：页面切到后台时，可能是用户切到投屏控制界面，适合上报日志或暂停音频 - 所有这些监听都需搭配
crossorigin="anonymous"，否则 Canvas 水印等后续操作会因 CORS 失败
真正起作用的防投屏不在 HTML 标签里
浏览器标签页本身不参与 Cast/Miracast/DLNA 协议协商，所谓“防”，其实是阻断外部设备发现、连接或拉取视频流的路径：
- 电视端关闭接收功能（如小米电视关“无线投屏”、LG webOS 关“允许设备连接”）是最直接有效的手段
- 后端提供带短时效 token 的视频 URL，并校验 UA/IP，让电视 WebView 无法复用链接
- HLS 的
.m3u8路径必须走登录态接口（如/api/play.m3u8?token=xxx），避免被直接访问 - 禁用 MSE：
if ('mediaSource' in window) { delete window.MediaSource; }，可让 hls.js/dash.js 失效，间接阻断 WebRTC/HLS 方案投屏
前端能做的，是增加投屏链路中的失败点，而不是构建一道可被绕过的 UI 防线。最容易被忽略的是：系统级镜像（macOS 镜像、Windows 投影到此电脑）完全不受 disableRemotePlayback 或 controlslist 影响——它们根本不经过浏览器渲染层。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
