disableRemotePlayback仅是提示性属性，非强制策略：Chrome/Edge中使投屏按钮变灰，Safari自iOS 15.4起部分响应，Firefox完全无视；无法阻止录屏、盗链或系统级投屏，需服务端token校验+代理流式分发兜底。
disableRemotePlayback 只能提示浏览器“别投屏”，不是锁，Chrome/Edge 里它会让投屏按钮变灰，Safari 从 iOS 15.4 起才部分响应，Firefox 完全无视。真想防投屏，得靠服务端策略兜底。
为什么 disableRemotePlayback 不可靠
这个属性是纯提示型的：浏览器收到后可以选择执行，也可以忽略。它不加密、不拦截、不校验请求来源，只影响右键菜单和地址栏里的 Cast/AirPlay 图标是否可见。
- 用户打开开发者工具 → Network 面板 → 找到 m3u8 或 mp4 请求 → 复制 URL → 粘贴到 VLC 或手机浏览器里，照样能投
- 用 macOS QuickTime 录屏 + AirPlay 到电视，
disableRemotePlayback完全没作用 - Android WebView、微信内置浏览器等环境行为不一致，设了也可能被绕过
真正起效的投屏防护组合
前端声明只是表层动作，关键在服务端对每次播放请求做上下文绑定：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 每个视频流 URL 必须走代理接口（如
/api/stream?videoId=xxx），而非直接暴露 S3 或 CDN 直链 - 后端生成带时效性与设备指纹绑定的 token，例如：
token=sha256(videoId+userId+uaHash+timestamp+secret)，有效期建议 ≤5 分钟 - 代理接口校验 token 后，再动态拉取原始资源并流式返回（不要缓存、不写死
Cache-Control: public） - 配合
Access-Control-Allow-Origin: https://your-domain.com和Referrer-Policy: strict-origin-when-cross-origin，防止跨域盗链
controlslist 和事件监听能补什么缺口
它不能阻止投屏本身，但能减少误操作入口和提供响应时机：
立即学习“前端免费学习笔记（深入）”；
- 写成
<video controls controlslist="noremoteplayback nodownload nofullscreen"></video>，比单用disableRemotePlayback多一层 UI 层压制 - 监听
webkitbeginfullscreen（Safari）或enterpictureinpicture（Chrome/Firefox），触发警告或主动video.pause() - 注意：
enterpictureinpicture是异步事件，不能在事件回调里直接调用exitPictureInPicture()，必须由用户手势触发后续操作
最易被忽略的一点：投屏风险常来自“已登录但非目标设备”的合法用户——比如员工用自己的 iPad 把内训视频投到会议室大屏上。这时候 token 绑定 UA + IP + 设备指纹就比单纯禁 UI 按钮管用得多。
