disableRemotePlayback必须以布尔属性形式直接写在video标签中才生效，即，禁用等号赋值；它仅向浏览器提示禁用投屏，非强制策略，Chrome/Edge支持良好，Safari部分支持，Firefox不支持。
disableRemotePlayback 属性怎么写才生效
它只在 Chrome/Edge（Chromium 内核）中可靠生效，Safari 自 iOS 15.4 起对 AirPlay 有部分提示效果，Firefox 完全不支持。关键在于写法必须是布尔属性形式：disableRemotePlayback，不能带等号、不能赋值。
错误写法会导致浏览器完全忽略该属性：
disableRemotePlayback="true"disableRemotePlayback="disabled"-
:disableRemotePlayback="isDisabled"（Vue 模板绑定也无效）
正确写法只有这一种：
<video controls disableRemotePlayback> <source src="video.mp4" type="video/mp4"> </video>
注意：该属性仅向浏览器“建议”不要启用投屏，不是强制策略，也不影响已开启的投屏会话。
立即学习“前端免费学习笔记（深入）”；
为什么加了 disableRemotePlayback 还能投屏
常见现象包括：Chrome 地址栏仍显示 Cast 图标、右键菜单里仍有“投射到设备”选项、用户手动点 Cast 按钮后仍能投整个标签页——这些都不算 bug，而是该属性的设计本质决定的。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
根本原因有三个：
- 它只禁用
<video></video>元素自身的投屏入口，不控制浏览器级投屏（如 Cast 标签页） - 它不拦截系统级屏幕共享或镜像（macOS 空气投送、Windows 投影到此电脑）
- 它对第三方投屏工具（如乐播、ApowerMirror）完全无感知、无约束力
也就是说，只要用户能操作浏览器或操作系统，就存在绕过路径。这不是实现问题，而是 HTML 标准能力边界所在。
想真正降低投屏风险，该组合哪些手段
单靠前端属性没用，必须前后端协同。以下是在生产环境验证有效的最小可行组合：
- 前端初始化时声明
disableRemotePlayback+controlsList="nodownload noremoteplayback"，减少 UI 上的误触入口 - 服务端对每个播放请求校验动态 Token（含
userId、videoId、timestamp、userAgentHash），过期时间严格控制在 5 分钟内 - 视频流走反向代理（如 Nginx 或 Cloudflare Workers），真实 S3/AWS URL 绝不暴露在 DOM 中
- 监听
webkitbeginfullscreen和enterpictureinpicture事件，在检测到异常全屏行为时主动pause()并上报
特别注意：DRM（如 Widevine）本身不解决投屏问题，但配合 license server 的 outputProtection 策略（如要求 HDCP），可在支持设备上限制高清输出——这需要客户端环境配合，不是加个属性就能开。
移动端和小程序里的坑
Android WebView 和微信/QQ 小程序环境对 disableRemotePlayback 支持极不稳定。实测发现：
- 微信内置 X5 内核（Android）多数版本直接忽略该属性
- iOS 微信使用 WKWebView，但自 iOS 17 起部分机型会降级为普通 AirPlay 提示，无法阻止
- 抖音/快手小程序完全不识别该属性，且其自研播放器屏蔽了所有原生 video 事件钩子
在这种环境下，更现实的做法是放弃前端防投屏幻想，转而强化服务端鉴权 + 动态水印（Canvas 叠加用户 ID + 时间戳）+ 关键帧加密（AES-128 for HLS）。物理盗录防不住，但至少让截下来的画面带身份痕迹、难二次传播。
