前端无法真正阻止投屏，仅能通过video.disableRemotePlayback=true隐藏按钮并配合webkitPresentationMode轮询检测投屏状态后暂停播放，但对已建立的投屏连接或系统级投屏无效，强防护需服务端DRM+硬件解密。
监听 webkitdisplayingfullscreen 和 fullscreenchange 事件没用？
直接监听这些事件无法阻止投屏，因为投屏（如 Chrome Cast、AirPlay）不触发标准全屏 API。浏览器在投屏时仍认为页面处于“窗口模式”，document.fullscreenElement 为 null，webkitdisplayingfullscreen 也完全不触发。这不是监听漏了，而是底层机制不同——投屏是独立于页面渲染进程的媒体通道重定向。
真正有效的检测：靠 HTMLMediaElement 的 webkitPresentationMode 属性
仅 Safari（macOS/iOS）和部分 Chromium 内核浏览器（如新版 Edge）支持该非标准但实际可用的属性。它会在投屏激活时返回 "picture-in-picture" 或 "remote"（后者即投屏状态），比监听事件更可靠。
实操建议：
html-to-pptx-converter
下载
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 轮询比事件监听更实用：
setInterval(() => { if (video.webkitPresentationMode === "remote") { video.pause(); } }, 500) - 必须配合
video.disableRemotePlayback = true（HTML 属性或 JS 设置），这是唯一能主动禁用投屏按钮的合法方式 - 注意兼容性：Firefox 不支持
webkitPresentationMode，且disableRemotePlayback在 Android WebView 中常被忽略
disableRemotePlayback=true 为什么有时失效？
这个属性只影响浏览器 UI 层的投屏按钮（如右键菜单、地址栏 Cast 图标），对已建立的投屏连接或系统级投屏（如 macOS 控制中心 AirPlay）无拦截能力。常见失效场景：
立即学习“前端免费学习笔记（深入）”；
- 视频元素未在 DOM 加载完成就设置该属性（需确保
video已挂载且src已赋值） - 使用了
preload="none"或动态设置src后未重新启用限制（需在loadedmetadata后再设一次disableRemotePlayback） - 某些安卓厂商定制浏览器（如华为 EMUI 内置浏览器）会无视该属性，此时只能靠服务端 DRM（如 Widevine L1）硬性限制
防投屏不是前端能独立完成的事
纯前端 JavaScript 无法真正阻止投屏行为，最多做到 UI 层隐藏按钮 + 检测后暂停播放。用户仍可通过系统快捷键（Cmd+Shift+5 录屏）、HDMI 抓帧、或抓包复现流地址绕过。真正需要防投屏的业务（如教育课件、付费直播），必须依赖服务端 DRM 授权 + 硬件级解密（L1 级别），前端只是配合策略的一环。把 disableRemotePlayback 当成保险丝可以，当成防火墙不行。
