html视频无法真正防投屏，前端仅能增加投屏失败概率；disableremoteplayback须写为无值布尔属性，controlslist="noremoteplayback"更兼容；需搭配crossorigin="anonymous"、监听enterpictureinpicture等事件；服务端鉴权和电视端关闭投屏接收才是有效防线。
HTML视频无法真正防投屏，前端能做的只是增加投屏链路中的失败点——不是“阻止”，而是让投屏更难成功、更容易中断。
disableRemotePlayback 属性怎么写才生效
这是 HTML5 原生唯一声明式提示，但极易写错。它不是开关，只向浏览器发一个“请勿投屏”的信号，且仅在部分环境起作用。
- 必须写成无值布尔属性：
disableRemotePlayback，不能带等号或引号 - 错误写法：
disableRemotePlayback="true"、disableRemotePlayback="disabled"、disableRemotePlayback="1"—— 浏览器直接忽略 - 仅 Chrome/Edge 可靠支持；Safari 从 iOS 15.4/macOS 12.3 起支持 AirPlay 提示；Firefox 完全不识别
- 动态设置（如
videoEl.setAttribute('disableRemotePlayback', '')）在 Safari 和多数 Android WebView 中无效，必须初始化时就写在 HTML 里
controlslist="noremoteplayback" 是更兼容的写法
controlslist 比 disableRemotePlayback 更早被支持，语义更明确，且可组合多个指令，适合兜底。
- 正确写法：
controlslist="nodownload noremoteplayback"（空格分隔，不加引号） - 它只隐藏右键菜单和地址栏的投屏图标，不影响已建立的投屏会话（比如用户先点 Cast 再刷新页面，投屏仍在继续）
- 在微信/X5 内核中大概率被忽略，需结合 UA 判断做降级提示，例如弹窗提醒“请在 Chrome 或 Safari 中观看”
- 必须搭配
crossorigin="anonymous"才能让后续 Canvas 水印、帧读取等逻辑正常工作，否则触发 CORS 错误
监听 enterpictureinpicture 和 webkitbeginfullscreen 做行为干预
UI 层限制会被快捷键、调试工具绕过，这时需要监听关键事件主动响应。
-
enterpictureinpicture：进入画中画时触发，可立即pause()并弹警告 -
webkitbeginfullscreen：Safari/Chrome 全屏前触发，比fullscreenchange更早，适合拦截 -
visibilitychange：切到后台时可能意味着用户已投屏成功，可暂停 + 上报行为日志 - 注意：
videoEl.addEventListener('enterpictureinpicture', () => { videoEl.pause(); })在部分 Android WebView 中不触发，需 fallback 到定时检测document.pictureInPictureElement
服务端才是防投屏的硬防线
所有前端手段都可被绕过，真正有效的控制必须落在服务端——因为投屏本质是“拉流”，而流地址才是命门。
- 避免使用静态公网 URL：
<video src="https://cdn.example.com/video.mp4"></video>→ 改为带短时效、绑定 UA/IP 的 token 鉴权地址，如/play?token=xxx&ts=1734770880 - HLS 的
.m3u8必须走登录态接口（如/api/v1/play.m3u8?session_id=abc），后端校验 session 有效性 - 禁用 MSE：
if ('mediaSource' in window) { delete window.MediaSource; }，让 hls.js/dash.js 失效，间接阻断 WebRTC/HLS 类投屏 - 响应头加
Access-Control-Allow-Origin: null+<video crossorigin="anonymous"></video>，让非同源脚本无法读取视频元信息
最容易被忽略的一点：电视端是否开启投屏接收功能，比任何前端代码都管用。小米关“无线投屏”、海信关“多屏互动”、LG 关“允许设备连接”——物理层关闭接收，才是最直接、最彻底的“防”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
