HTML本身无法真正防投屏，因投屏属系统级行为，video标签加oncontextmenu无效；有效手段是让录屏画面不可用（如canvas动态绘帧+SVG水印）、禁用原生controls改用键盘可操作自定义控件，并避免破坏字幕与焦点管理。
HTML 和 CSS 层面没有权限拦截系统级屏幕共享。所谓“防投屏”，实际目标是**降低被非授权投屏/录屏的成功率或清晰度**，同时**不显著损害合法用户的观看体验**——这点常被忽略，导致开发者一上来就加 pointer-events: none 或禁右键，结果连字幕点击、进度条拖拽都失效。
为什么 video 标签加 oncontextmenu="return false" 没用
这个操作只能禁浏览器右键菜单，但 macOS 的 QuickTime、Windows 的 Xbox Game Bar、甚至 Chrome 自带的「捕获窗口」功能，根本不走 DOM 事件流。用户点「投屏」时，系统直接从 GPU 后备缓冲区或显示合成器抓帧，oncontextmenu 连边都碰不到。
哪些 HTML/CSS/JS 手段真能干扰录屏但又不卡主流程
真正起作用的，是让录屏/投屏工具拿到的画面「不可用」或「信息残缺」，同时保留正常播放：
-
canvas+requestVideoFrameCallback动态绘制视频帧，并在关键区域（如水印位）叠加半透明 SVG 图层——多数录屏工具对 canvas 内容识别率低，且无法分离图层 - 用
MediaStream替代src，配合MediaRecorder实时添加动态噪声帧（仅对录屏生效，人眼不可辨），但需注意 Safari 对MediaRecorder的支持仍有限 - 禁用
video的controls，改用自定义控件，并把播放按钮、音量滑块等绑定到div上——部分投屏工具会跳过非原生控件区域，导致操作失灵，但用户可通过键盘空格/方向键继续操作 - 避免使用
object-fit: cover配合overflow: hidden裁剪画面，某些投屏协议（如 Miracast）会强制重采样，反而放大黑边或模糊边缘
WebRTC 与 MSE 方案对投屏兼容性的真实影响
用 MediaSource + ArrayBuffer 分片加载视频，比直接 src 更难被第三方工具识别为“可投视频流”。但代价明显：
- Chrome 120+ 对 MSE 的硬件解码支持良好，但 iOS Safari 仍强制走软解，4K 视频易掉帧
- 启用了
encrypted-media扩展后，部分会议室投屏设备（如 Barco ClickShare、Crestron AirMedia）会直接拒绝连接，报错NotSupportedError: Failed to load because no supported source was found - 若服务端返回的
Content-Type是application/vnd.apple.mpegurl（HLS），而客户端用 MSE 加载，iOS 会静默失败——必须 fallback 到video原生 HLS 支持
最常被忽略的体验断点：字幕与焦点管理
加了防录逻辑后，track 标签里的 kind="subtitles" 很容易被忽略。一旦启用自定义渲染（比如用 VTTCue + canvas 绘制字幕），焦点会脱离 video 元素，导致：
立即学习“前端免费学习笔记（深入）”；
- 键盘
↑↓调节音量失效（焦点不在 video 上） - 全屏切换后字幕位置错乱（CSS transform 未同步重算）
- 屏幕阅读器无法读出当前字幕文本（缺少
aria-live和 role 更新）
正确做法是保持 video 元素始终可聚焦，并用 getVideoPlaybackQuality() 监听卡顿，卡顿时主动暂停并提示用户——比强行防录更尊重真实使用场景。
