网页无法拦截投屏请求，因浏览器未提供相关API，这是出于安全限制；所有前端方案（如visibilitychange、disablePictureInPicture）仅影响UI或录屏，对硬件投屏无效；真正防护需EME+商业DRM、原生App权限或投屏检测告警。
投屏请求无法用HTML或JavaScript拦截
浏览器不提供任何API让网页主动拒绝或拦截cast、screen-capture或系统级投屏（如Chromecast、Miracast、macOS AirPlay）。这是刻意设计的安全限制——网页无权干涉用户对自身设备的控制权。所谓“防投屏”在标准Web环境中本质不可行，所有声称“用document.addEventListener('visibilitychange')或blur事件隐藏视频”的方案，都只能干扰录屏软件的窗口捕获，对硬件投屏完全无效。
为什么disablePictureInPicture和webkit-playsinline没用
这些属性只影响播放器UI行为，与投屏协议无关：
• disablePictureInPicture="true" 仅禁用画中画，不影响chrome.cast；
• webkit-playsinline 让iOS视频内联播放，反而可能增加被AirPlay镜像捕获的概率；
• 移除controls或监听contextmenu右键菜单，对系统级投屏请求零阻断能力。
真正起作用的只有服务端+客户端协同方案
若业务强依赖防投屏（如DRM内容分发），必须放弃纯前端思路：
• 使用EME（Encrypted Media Extensions）配合商业DRM服务（如Widevine、FairPlay），让解密密钥不暴露给网页JS，投屏端因无密钥无法解码；
• Android/iOS原生App可调用平台API（如Android的MediaRouter监听、iOS的AVRoutePickerView）主动禁用投屏按钮，但WebView内嵌网页仍无权限；
• 部分企业级方案（如腾讯云TRTC、声网Agora）提供“投屏检测”回调（onScreenSharingStarted），仅用于告警或降清晰度，非拦截。
容易被忽略的关键事实
• 投屏本质是操作系统/固件层的音视频流重定向，浏览器连帧数据都拿不到，更别说拦截；
• 即使禁用getUserMedia、屏蔽chrome.cast API，用户仍可通过系统快捷键（Win+K、Cmd+P）强制发起；
• 所有前端“防投屏”代码在DevTools里删掉一行就失效，毫无实际防护意义；
• 真正需要保护的内容，不该放在开放Web环境里交付。
立即学习“前端免费学习笔记（深入）”；
