HTML video 标签无法通过前端禁用投屏，disableRemotePlayback 仅弱约束部分场景；真正有效防护需服务端动态控制媒体源，如 MSE 分片校验 token、短时效密钥轮换及动态水印。
HTML video 标签默认支持投屏，无法通过前端禁用
浏览器原生 video 元素只要启用了 webkit-playsinline 或 playsinline，且系统/设备支持（如 Chrome on Android、Safari on iOS/macOS），就会自动显示投屏按钮。你加 disablePictureInPicture、监听 enterpictureinpicture 事件或移除 controls，都**不影响投屏入口的存在**——因为它是浏览器 UI 层功能，不由页面 JS 控制。
更关键的是：投屏本质是将当前 tab 的媒体流推送到接收端（Chromecast/AirPlay），它不依赖视频 URL 是否可访问，也不触发新的 HTTP 请求，所以防盗链、Referer 校验、Token 验证等手段在投屏场景下完全失效。
-
disablePictureInPicture="true"只隐藏按钮，但用户仍可通过系统级快捷键（如 macOS 的菜单栏 AirPlay 图标）发起投屏 - 拦截
enterpictureinpicture事件只能暂停播放，无法阻止投屏会话建立 - 移除
controls后，部分浏览器仍会在长按/右键菜单中提供“投射到设备”选项
webkit-video-play 和 disableRemotePlayback 的真实效果
disableRemotePlayback="true" 是目前唯一被 Chromium 和 Safari 支持的、能真正抑制投屏行为的属性，但它只对「远程回放」（Remote Playback API）生效，不覆盖 AirPlay/Chromecast 的原生集成路径。实测结果：
- Chrome on Windows/Linux：设为
true后，地址栏投屏图标消失，navigator.canPlayType()返回空字符串，但按Ctrl+Shift+M仍可强制唤起媒体控制中心并投屏 - Safari on macOS：该属性无效，AirPlay 菜单始终可见且可用
- Android Chrome：设为
true可隐藏投屏按钮，但开发者工具 > Rendering > Emulate network conditions 下启用 “Throttling” 后，按钮又会出现——说明它受渲染上下文影响，不稳定
换句话说：disableRemotePlayback 是弱约束，不是安全边界。它只能挡住一部分非技术用户的点击操作，对有意投屏者形同虚设。
立即学习“前端免费学习笔记（深入）”；
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
真正有效的防投屏 = 不让投屏内容可播
既然无法阻止投屏动作本身，就只能确保「投出去的内容是不可用的」。核心思路是：投屏流必须来自当前页面的媒体源，而这个源可以被服务端动态控制。
- 改用 MSE（Media Source Extensions）加载分片，每次
sourceBuffer.appendBuffer()前校验 session token 是否仍在有效期；token 过期则中断 append，投屏端立刻黑屏或报错 - 结合 WebRTC 模拟流式传输：后端用
ffmpeg将 MP4 实时转为 fMP4 + HLS 分片，并注入 AES-128 密钥轮换逻辑；密钥由后端按需下发，前端解密失败即无法渲染，投屏自然无画面 - 对高敏感内容，在播放器层叠加 canvas 动态水印（含用户 ID、时间戳、设备指纹哈希），并设置
canvas.style.mixBlendMode = 'exclusion'干扰录屏识别——虽然不能防投屏，但大幅降低盗录后的二次分发价值
注意：HLS 的 #EXT-X-KEY 加密对投屏无效，因为 Safari/Chrome 在投屏时会绕过前端 JS，直接向原始 m3u8 URL 发起请求并缓存解密密钥。必须用服务端实时生成密钥 + 绑定会话 ID，且密钥有效期 ≤ 30 秒。
CDN 和 Nginx 层对投屏毫无感知
所有基于 Referer、User-Agent、IP 频率、Token 参数的 CDN 防盗链规则，对投屏流量完全不生效。原因很直接：投屏建立后，媒体数据是从浏览器本地 media pipeline 推送出去的，**不经过任何 HTTP 请求**。CDN 日志里看不到投屏相关 access log，Nginx 的 $http_referer 和 $arg_token 全为空。
试图在 Nginx 里用 if ($args !~ "token=[a-f0-9]{16}") { return 403; } 拦截投屏？没用。它拦的是你页面里 fetch() 的分片请求，不是投屏通道。
所以，别在 CDN 配置里浪费时间写投屏相关规则。重点应放在：服务端是否能及时终止正在播放的会话（比如用户登出、token 撤销），以及 MSE/HLS 解密环节是否足够短生命周期、强绑定。
投屏不是“链接被盗”，而是“当前会话被镜像”。防护重心从来不在 URL 上，而在播放器与服务端之间那条有状态、有时效、带上下文的通信链路上。一旦这条链路断开或校验失败，投屏端拿到的就是静帧、黑屏或解密错误——这才是实际可控的防线。
