HTML无法直接拦截无线投屏，因浏览器未提供API检测或阻止Miracast/AirPlay/Chromecast等系统级行为；所谓“防投屏”需依赖DRM、HDCP、服务端鉴权等全链路闭环措施，前端JS仅能有限辅助。
HTML 无法直接拦截无线投屏
浏览器没有提供任何 API 允许网页主动检测或阻止 Miracast、AirPlay、Chromecast 等系统级无线投屏行为。所谓「防投屏」，本质上是绕过浏览器沙箱、依赖操作系统或硬件层的控制，而 HTML/JS 运行在受限环境中，navigator.getDisplayMedia 或 screen.orientation 等接口都与投屏状态无关，也无法触发拦截。
常见“防投屏”方案的实际效果和限制
很多项目尝试用以下方式“对抗”投屏，但效果有限且容易被绕过：
-
document.addEventListener('visibilitychange')只能监听标签页是否被切换或最小化，对 AirPlay 投屏中的页面仍处于可见状态完全无效 - 监听
screen.orientation变化或window.matchMedia('(orientation: landscape)')—— 投屏时设备方向不变，不触发 - 用
canvas绘制视频帧再叠加干扰色块 —— 投屏通常捕获的是原始视频流（<video></video>元素）或系统桌面，Canvas 内容未必被同步捕获，且影响正常观看体验 - 禁用右键、F12、复制等操作 —— 对投屏零防护作用，用户只需打开系统投屏功能即可
真正起作用的环节在播放器和后端
防投屏不是前端能独立解决的问题，必须结合播放链路各环节协同：
- 使用支持 DRM 的播放器（如
shaka-player或dash.js配合 Widevine/PlayReady），让视频解密和渲染绑定到受保护的媒体路径（MediaSource+encrypted media extensions），部分平台（如 Chrome on Windows/macOS）会在检测到非可信输出（如 Miracast）时自动降级为黑屏或静音 - 服务端开启 HDCP 检测（需硬件支持），通过 CDM 返回
keyStatuses中的"status"字段判断输出链路是否可信；若为"output-downscaled"或"output-not-allowed"，可主动暂停播放并提示 - 避免使用
<video src="xxx.mp4"></video>直播式链接 —— 明文 URL 可被任意抓取，应改用带时效签名的 HLS/DASH 流，配合 token 鉴权
移动端 iOS/Android 的特殊表现
iOS Safari 对 AirPlay 有更严格的输出控制逻辑：
立即学习“前端免费学习笔记（深入）”；
- 当
<video></video>设置webkit-playsinline且未启用controls，系统可能默认禁用 AirPlay 按钮（但用户仍可通过控制中心强制投） - 调用
video.webkitShowPlaybackTargetPicker()是显式唤出投屏选择器，不调用 ≠ 禁止投屏，只是隐藏入口 - Android Chrome 几乎不提供投屏状态反馈，
screen.orientation.lock('landscape-primary')之类操作对 Chromecast 无约束力
最易被忽略的一点：即使所有前端手段都加上，只要视频资源本身能被下载或被代理截获（比如没做 Referer 校验、没走 HTTPS、没设 CORS 隐藏），投屏就形同虚设。防投屏的关键不在 HTML，而在整个媒体交付链路是否闭环可信。
