disableremoteplayback 必须作为布尔属性直接写在标签中，不赋值、不加等号，如；disableremoteplayback="true"等写法均无效。
disableRemotePlayback 属性怎么写才生效
直接写 disableRemotePlayback 就行，不能带等号、不能赋值，否则浏览器当普通字符串处理，完全忽略：<video controls disableremoteplayback></video>
常见错误写法包括：disableRemotePlayback="true"、disableRemotePlayback="disabled"、disableRemotePlayback=""——这些都会导致属性失效。
Chrome 和 Safari 的实际表现差异
Chrome / Edge（Chromium 内核）下该属性效果较稳定：投屏图标从地址栏消失，右键菜单里也移除了“投射到设备”选项；Safari 自 iOS 15.4 和 macOS 12.3 起支持，但仅对 AirPlay 有提示作用，且部分机型或系统版本仍会显示灰色不可点的入口，用户长按可能绕过；Firefox 完全不识别该属性，设了等于没设。
为什么加了 disableRemotePlayback 还能被投屏
- 它只是向浏览器“建议”禁用远程播放，不是强制策略，底层平台（如 Android TV、macOS 系统服务）可能无视该信号
- 用户可在视频播放前手动打开 AirPlay/Chromecast 控制中心，再选择当前标签页——此时
disableRemotePlayback不起作用 - 如果页面用了
webkit-playsinline或playsinline，在 iOS 上可能触发更宽松的投屏逻辑 - 该属性对系统级镜像（如 macOS 的“屏幕共享”、Windows 的“无线显示”）完全无效
真正需要防投屏时，还得靠后端配合
前端加属性只是第一道提示，要降低被投屏后二次传播的风险，必须叠加服务端控制：
– 视频流走代理接口（如 /api/stream?vid=abc&token=xyz），每次请求校验用户身份与设备指纹
– HLS 分片 URL 带短时效签名（建议 ≤ 60 秒），过期即 403
– 配合 crossorigin="anonymous" + Canvas 动态水印，让投屏画面自带用户 ID 和时间戳
– 在播放器初始化时检查 navigator.mediaDevices.getSupportedConstraints().remotePlayback，不支持时降级提示
容易被忽略的一点：即使禁用了投屏 UI，只要视频资源本身没加密、没鉴权，用户仍可抓包拿到 m3u8 地址，用 VLC 直接加载并投屏——所以 disableRemotePlayback 必须和动态 Token、分片加密一起用，单独存在几乎无防护价值。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
