HTML无法真正屏蔽投屏协议，因系统级投屏（如Cast、AirPlay）不经过JS控制；仅能通过noremoteplayback隐藏按钮、禁用MediaSession降低便利性；真正防护需DRM+服务端策略。
HTML 本身无法真正“屏蔽投屏协议”来实现视频防投屏——这是个常见误解。浏览器和操作系统层面的投屏（如 Chrome 的 Cast、Windows 的无线显示、macOS 的 AirPlay）不经过 HTML 或 JavaScript 控制，而是由系统级媒体管道接管。你写的 <video> 标签一旦播放，只要用户能看见画面，就存在被录屏、镜像或投屏的风险。
为什么 disablePictureInPicture 和 webkit-playsinline 不防投屏
这些属性只影响浏览器内行为，和系统投屏无关：
-
disablePictureInPicture="true"仅禁用画中画，不影响 Chromecast/AirPlay -
webkit-playsinline和playsinline只让 iOS 视频在页面内播放（而非全屏 native player），但 AirPlay 按钮仍会出现在控制栏 - 监听
webkitbeginfullscreen或enterpictureinpicture事件，也无法拦截系统级投屏触发
能做的有限干预：隐藏投屏控件 + 阻断部分 API
虽然不能阻止投屏动作本身，但可降低普通用户的操作便利性：
- 移除原生控件中的投屏按钮：
<video controlslist="nodownload noremoteplayback" ...>——noremoteplayback是关键，它告诉浏览器“此视频不支持远程播放”，多数 Chromium 浏览器会隐藏 Cast 按钮（但 iOS Safari 忽略该属性） - 禁用
MediaSession防止投屏设备识别媒体元数据：if ('mediaSession' in navigator) { navigator.mediaSession.metadata = null; navigator.mediaSession.setActionHandler('play', null); navigator.mediaSession.setActionHandler('pause', null); } - 避免调用
navigator.mediaDevices.getDisplayMedia()，防止页面主动发起屏幕共享（这不是投屏，但常被混淆）
真正防投屏？得靠服务端和客户端协同
纯前端 HTML/JS 方案注定失效。如果业务真有强防盗需求（如教育平台 VIP 课程）：
立即学习“前端免费学习笔记（深入）”；
- 视频必须使用 DRM（如 Widevine、FairPlay），且播放器走 MSE + EME 流程，
<video>只是容器，解密和渲染由 CDM 控制——此时系统投屏通常被 DRM 策略拦截（例如 Widevine L1 设备才允许高清投屏，L3 下直接黑屏或报错DRM_ERROR_DECRYPT） - 自研播放器配合 SDK 做运行时环境检测：检查
window.screen.orientation.type是否突变、监听document.visibilityState+screen.isSecureContext组合异常、甚至通过 WebGL 渲染指纹判断是否处于虚拟/录屏上下文（效果有限，且 iOS 完全不可行） - 放弃“防投屏”，转向“防扩散”：水印（动态时间戳+用户 ID 叠加在视频帧上）、限制播放域名（Referer / CORS）、短时效播放凭证（JWT 过期时间 ≤ 15 分钟）
记住：只要视频帧能被 GPU 渲染出来，就存在被截取的路径。所谓“HTML 防投屏”，本质是在 UI 层做障眼法；真要约束分发，必须把控制点前移到 DRM 授权链和服务端策略里。前端能做的，只是让随意投屏多点阻碍，而不是筑墙。
