disableRemotePlayback在微信内置浏览器中基本无效，因X5内核和WKWebView支持极弱，仅作提示用；真正有效的防护需结合服务端鉴权、JS事件监听（如webkitbeginfullscreen）及DRM等综合手段。
disableRemotePlayback 属性到底有没有用
在微信内置浏览器里加 disableRemotePlayback，基本等于没加。它只是个提示性属性，Chrome/Edge 里能隐藏投屏图标，但微信用的是 X5 内核（Android）或 WKWebView（iOS），这两个环境对这个属性的支持极弱——实测多数机型完全忽略，右上角 AirPlay/Chromecast 图标照常出现，点击后照样投屏。
更关键的是，即使浏览器识别了该属性，也只影响“远程播放菜单”，不阻止系统级录屏、镜像投射、采集卡抓流等行为。所以别指望靠它防住盗录。
正确写法必须是布尔属性形式：<video disableremoteplayback></video>；disableRemotePlayback="true" 或 disableRemotePlayback="disabled" 都会失效。
微信里真正能干预投屏的只有 JS 事件监听
微信浏览器（尤其是 iOS 端）会触发 webkitbeginfullscreen 和 enterpictureinpicture 这两个事件，虽然不能阻止投屏动作本身，但可以立刻暂停播放、弹出遮罩或跳转提示页。
立即学习“前端免费学习笔记（深入）”；
实操建议：
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
- 监听
webkitbeginfullscreen后立即调用video.pause()，并显示“检测到投屏行为，已暂停播放”提示 - 配合
document.addEventListener('visibilitychange', ...)检测页面切后台，防止用户切到其他 App 后继续投屏 - iOS 微信中
enterpictureinpicture触发较晚，需提前在loadedmetadata阶段绑定，否则容易错过 - 注意：X5 内核 Android 微信几乎不触发这些事件，所以该方案主要覆盖 iOS 场景
服务端鉴权才是防投屏的第一道防线
前端所有手段都是“软防护”，真正起效的是服务端对视频请求的拦截。微信内打开的页面，其 Referer、User-Agent、IP、甚至微信 OpenID（通过 JS-SDK 获取）都可作为校验依据。
常见组合策略：
- 视频资源 URL 带一次性 Token，10 分钟过期，且绑定当前设备 UA + 微信 openid
- CDN 层配置 Referer 白名单，只允许你的域名和微信内置浏览器 UA 访问
- 对 HLS/M3U8 请求做动态密钥校验，每次生成不同
KEY，避免被缓存复用 - 禁用跨域资源共享（CORS），防止其他站点 iframe 嵌入后绕过前端控制
这些措施不会让视频“看起来更防投屏”，但能让盗录者无法稳定获取原始媒体流——这才是成本最低、效果最实的防线。
别忘了物理层面根本防不住
只要视频能在屏幕上渲染、声音能从扬声器输出，就存在被手机拍摄、采集卡截取、系统录屏捕获的可能。所有前端 JS 控制、disableRemotePlayback、事件拦截，都拦不住这三类操作。
真正需要高保密度的场景（如付费网课），必须搭配：
- DRM 方案（Widevine/FairPlay），配合 license server 输出保护策略（如强制 HDCP）
- 播放器层注入水印（时间戳+用户 ID 叠加在视频画面上）
- 服务端记录异常播放行为（如短时间内多设备并发请求同一资源）
把希望全押在 HTML 属性或一个事件监听上，是绝大多数防盗录失败的起点。
