disableRemotePlayback 仅是浏览器UI层投屏入口的建议性禁用属性，不具强制性，需与服务端动态播放凭证（如预签名URL+三重校验）协同才能实现有效防投屏。
disableRemotePlayback 是 HTML5 <video></video> 标签唯一原生支持的防投屏提示属性，但它本身不校验凭证、不加密、不拦截请求——播放凭证（如 JWT 或 HMAC Token）和防投屏是两个独立层面的事，必须前后端协同才能形成有效约束。
disableRemotePlayback 的正确写法与常见失效原因
它只是向浏览器“建议不要投屏”，不是强制策略，不能靠它挡住已拿到视频 URL 的用户
-
必须以布尔属性形式直接声明，不能赋值：
<video controls disableRemotePlayback> <source src="https://example.com/video.mp4" type="video/mp4"> </video>
-
错误写法（会被浏览器忽略）：
disableRemotePlayback="true"、disableRemotePlayback="disabled"、:disableRemotePlayback="true"（Vue 模板中未加 .sync 或未用 v-bind 动态绑定也会失效）立即学习“前端免费学习笔记（深入）”；
Safari 自 iOS 15.4 起支持 AirPlay 禁用提示，Chrome/Edge 支持良好，Firefox 完全不支持
-
即使属性生效，用户仍可：
- 用系统录屏（macOS QuickTime、Windows Xbox Game Bar）
- 手机拍摄投屏画面
- 抓包提取分片 URL 后本地下载（尤其 HLS/DASH 场景）
播放凭证如何真正参与防投屏控制
播放凭证本身不作用于 disableRemotePlayback，但它能限制「谁有资格获得可播放的资源」，从而让投屏行为失去前提：
- 前端不直接写死
src，而是先请求播放接口（如/api/video/play?videoId=abc），携带用户身份上下文（Cookie 或临时 Token） - 后端校验该凭证是否合法、未过期、绑定当前设备/IP/UserAgent，并动态生成一个5 分钟内有效、单次可用或 UA 绑定的预签名 URL
- 这个 URL 不是 S3 直链，而是经过网关代理的流地址（如
/stream/vid_abc?token=xyz&exp=1734646560），服务端在响应前做 Referer、Origin、User-Agent 三重校验 - 若凭证校验失败，返回
403；若成功，才返回带Content-Range支持的流式响应（否则拖拽、暂停会失败）
关键点：
-
disableRemotePlayback控制的是「浏览器 UI 层是否显示投屏入口」 - 播放凭证控制的是「服务端是否允许这个请求进入媒体流管道」
两者叠加，才能让普通用户看不到投屏按钮，同时让技术用户即使打开 DevTools 也拿不到长期有效的播放地址。
动态设置 disableRemotePlayback 的兼容性陷阱
部分业务想根据用户权限动态开启/关闭该属性，比如 VIP 用户允许投屏、普通用户禁止：
- 在 Chrome/Edge 中，初始化后动态设置
video.disableRemotePlayback = true大概率无效（属性只在元素挂载时读取一次） - 更可靠的做法是：服务端渲染时就决定是否写入该属性，或用 JS 创建新
<video></video>元素并完整声明 - 若用 React/Vue，确保该属性是静态布尔 prop，而非字符串或响应式变量（如 Vue 中应写
disableRemotePlayback，而非:disableRemotePlayback="true"）
真正难防的从来不是投屏按钮，而是用户已经拿到视频字节流后的所有后续操作。播放凭证的价值不在“防投屏”，而在“让每一次播放请求都可追溯、有时效、有上下文”。把凭证验证做扎实了，disableRemotePlayback 才不是摆设。
