disableRemotePlayback是唯一真正起效的HTML原生防投屏属性，它向浏览器发出禁用远程播放（如AirPlay、Chromecast）的提示，但仅作提示非强制策略，不阻止系统级屏幕镜像或第三方录屏。
HTML 视频防投屏失效，本质不是“防不住”，而是开发者误用了浏览器原生能力或混淆了协议层级。现代浏览器对 <video> 元素的投屏控制权非常有限——disablePictureInPicture、controlsList="nodownload nofullscreen" 这类属性只能影响本地 UI，**完全不阻止系统级投屏（如 AirPlay、Miracast、DLNA）**。真要限制，得从协议、网络、播放器行为三处下手。
为什么 webkit-playsinline 或 playsinline 不能防投屏
这两个属性只告诉 iOS Safari “允许视频在页面内播放”，避免全屏跳转；它和投屏功能毫无关系。开启后用户依然能点右上角 AirPlay 图标投到 Apple TV，或用系统快捷菜单镜像整个屏幕。更关键的是：playsinline 在安卓 Chrome、Edge 等非 WebKit 内核中基本无效，纯属 iOS 特供兼容写法。
常见误操作：
- 把
playsinline当成“禁投屏开关”，加了就以为安全了 - 在安卓设备上测试时发现没反应，又加一堆 vendor prefix，结果仍无实质作用
- 依赖这个属性做 DRM 判断逻辑，导致授权校验在投屏场景下绕过
disableRemotePlayback 是唯一真正起效的 HTML 属性
这是 W3C 标准定义的布尔属性，作用是**禁止浏览器将视频输出到远程设备**。它会影响 AirPlay（iOS/macOS）、Google Cast（Chrome/Android）、Windows 设备的 Miracast 投射入口。
立即学习“前端免费学习笔记（深入）”；
但要注意三点：
- 必须显式设为
disableRemotePlayback="true"，仅写disableRemotePlayback（无值）在部分旧版 Safari 中不生效 - 仅对
<video>元素本身有效；如果页面用 JS 动态创建 video 元素，需在插入 DOM 前手动 setAttribute - 不阻止屏幕镜像（Screen Mirroring）：用户仍可镜像整个浏览器窗口，这是操作系统层行为，HTML 无法干预
示例写法：
<video src="demo.mp4" disableRemotePlayback="true" controls></video>
投屏仍成功？检查是否触发了“降级路径”
即使加了 disableRemotePlayback="true"，某些场景下投屏仍会成功，常见原因有：
- 视频使用了 MSE（Media Source Extensions）动态加载，而浏览器在 MSE 模式下忽略该属性（Safari 16.4+ 已修复，但旧版本大量存在）
- 页面同时加载了第三方播放器 SDK（如阿里云播放器、腾讯云 VOD），它们内部调用 WebRTC 或自建投屏通道，绕过了原生
<video>控制 - 用户通过系统快捷键（如 macOS 的
Cmd+Shift+5录屏并投射）或第三方工具（OBS、Scrcpy）捕获画面，这类属于桌面级抓取，HTML 层面无感知也无权限拦截
验证方式：打开 Chrome DevTools → Application 标签页 → 查看 Frames 下 video 元素的属性列表，确认 disableRemotePlayback 是否为 true；再用 Safari 打开同一页面，点击地址栏旁的 AirPlay 图标，观察是否灰显或消失。
真正需要防投屏的场景，别只靠 HTML 属性
如果业务明确要求“内容不可外投”（如 DRM 保护课程、内部会议录像），单靠前端 HTML 属性远远不够。此时应转向协议层控制：
- 启用 EME（Encrypted Media Extensions）配合 Widevine / FairPlay，让投屏设备因缺少证书而解密失败（黑屏）
- 服务端识别 User-Agent + Referer + IP，对已知投屏设备 UA（如
AppleCoreMedia、DLNADOC）返回 403 或低码率流 - 在播放器 JS 层监听
webkitcurrentplaybacktargetiswirelesschanged事件，检测到无线输出立即 pause 并提示“不支持投屏播放”
最容易被忽略的一点：很多团队花大力气调试 disableRemotePlayback，却忘了检查 CDN 是否缓存了未带该属性的老版本 HTML 页面——清 CDN 缓存比改代码更重要。
