disableRemotePlayback 仅是提示性属性，非安全机制，无法真正防投屏；它仅影响浏览器UI投屏按钮显示，对录屏、抓包、分片提取等无效，且需以无值形式书写，配合controlslist="noremoteplayback"及服务端鉴权、加密、DRM才构成有效防护。
disableRemotePlayback 是唯一原生可用的防投屏提示属性，但它不强制生效，也不能替代服务端鉴权或 DRM。
为什么 disableRemotePlayback 不能真正“防止”投屏
这个属性只是向浏览器发出“不希望此视频被投屏”的信号，不是安全策略。Chrome/Edge 会隐藏 Cast 图标或置灰 AirPlay 按钮；Safari 自 iOS 15.4 起支持但仅限 AirPlay 提示；Firefox 完全忽略该属性。它对系统级录屏、手机拍摄、抓包下载、HLS 分片提取等行为零防护能力。
-
disableRemotePlayback="true"或disableRemotePlayback="disabled"是错误写法，浏览器直接忽略 - 必须以无值布尔属性形式书写：
<video disableRemotePlayback> - 动态 JS 设置（如
video.disableRemotePlayback = true）在部分浏览器中不触发 UI 更新
controlslist="noremoteplayback" 和 disableRemotePlayback 的区别
两者目标一致，但作用层级不同：disableRemotePlayback 是 HTML5 媒体规范定义的原生属性，影响浏览器底层投屏发现逻辑；controlslist="noremoteplayback" 是控制条 UI 层的隐藏指令，只移除播放器界面上的投屏按钮（比如右键菜单里的“投射到设备”），不干预底层协议。
- 推荐同时使用：
<video controls disableRemotePlayback controlslist="noremoteplayback"> -
controlslist还可叠加nodownload、nofullscreen等参数，一并控制 UI 行为 - 若页面已禁用
controls（自定义控件），则controlslist失效，仅disableRemotePlayback仍可能起提示作用
前端设置之外，必须补的服务端防护点
仅靠 HTML 属性无法构成有效防线。真实风险来自 URL 泄露和未授权访问，必须从请求源头控制：
立即学习“前端免费学习笔记（深入）”；
- 避免将原始视频 URL 直接写入
src，改用后端代理接口返回带签名的临时地址（如/proxy/video/abc123?t=1734690000&s=xyz） - 校验请求头：
Referer（防外链）、User-Agent（过滤脚本工具）、Authorization（JWT 或 session 绑定） - 对 HLS/DASH 流启用 AES-128 加密，并由后端动态下发密钥 URL，禁止前端硬编码或缓存
- 敏感内容启用 DRM（Widevine/FairPlay），并在 license server 配置
outputProtection策略限制 HDCP 输出
真正难防的是物理盗录和系统录屏——这些连操作系统都不拦截，HTML 层更无能为力。把精力放在 URL 动态化、请求上下文校验和流加密上，比纠结 disableRemotePlayback 是否生效更实际。
