disableRemotePlayback是纯前端HTML布尔属性，不依赖OSS/S3权限，不触发鉴权、不读取header、不校验签名；正确写法为，服务端无需任何特殊配置。
HTML视频防投屏不需要对象存储（OSS/S3）或 CDN 的任何特殊权限，disableRemotePlayback 是纯前端 HTML 属性，不触发鉴权、不读取 header、不校验签名——配错了权限策略反而会暴露资源或阻断正常播放。
disableRemotePlayback 属性本身不依赖任何服务端权限
它只是浏览器渲染时的一个提示信号，和后端权限模型完全解耦。你在 <video></video> 标签里写 disableRemotePlayback，对象存储侧无需配置 RAM Policy、Bucket Policy、CORS 中的任何额外字段，也不需要给 Object 加 metadata 或 tag。试图在 OSS 控制台找“禁投屏开关”或添加 disableRemotePlayback=true 的 object tag，只会白忙一场。
常见误解包括：
- 以为要给 OSS 配
oss:DisableRemotePlayback权限——根本不存在这个权限项 - 以为需在 CORS 中显式允许
disableRemotePlaybackheader——该属性不发任何 header - 以为私有 Bucket + 签名 URL 就能让
disableRemotePlayback生效——它是否生效只看浏览器是否识别，和 URL 是否带签名无关
真正需要配权限的地方是代理接口或流服务
如果你走的是「服务端鉴权代理」路线（推荐），那权限控制点不在 OSS，而在你自己的 API 接口和 OSS 的调用链路上：
立即学习“前端免费学习笔记（深入）”；
- 后端服务（如 Node.js/Python）必须拥有
oss:GetObject（阿里云）或s3:GetObject（AWS）权限，且Resource严格限制到视频目录前缀，例如"arn:aws:s3:::my-bucket/videos/*" - OSS Bucket 的 CORS 配置必须允许你的前端域名，并显式允许自定义 header（如
x-video-token），否则代理加的校验头会被浏览器拦截 - 若用 CloudFront / CDN 回源到 OSS，需在 CDN 层配置
Referer和User-Agent白名单（注意：Referer可伪造，仅作辅助） - 绝对禁止对视频目录开放
ListObjects权限——否则攻击者可通过遍历前缀获取全部视频 Key
controlslist="noremoteplayback" 不是权限问题，是兼容性陷阱
这个属性和 disableRemotePlayback 目标一致，但作用层级不同：前者是控制条 UI 行为修饰符，后者是元素级提示。它们可以共存，但不会叠加效果，且都不依赖任何服务端权限。
关键兼容性事实：
-
controlslist="noremoteplayback"在 Safari 中支持极弱，部分版本甚至完全忽略 -
disableRemotePlayback必须写成无值布尔形式：<video disableremoteplayback></video>；写成disableRemotePlayback="true"或disableRemotePlayback=""会被所有主流浏览器忽略 - 在微信内置浏览器、QQ 浏览器等 X5 内核环境里，两者大概率都被跳过，需额外判断 UA 并降级提示
最常被忽略的一点：即使所有 HTML 属性都写对了，只要视频地址是明文写死在 HTML 中（比如 src="https://cdn.example.com/lesson.mp4"），用户复制链接后用 VLC 直接打开，就彻底绕过了所有前端限制——这时真正起作用的，是你后端是否做了动态 Token 鉴权、是否绑定了设备指纹、是否设置了短时效。前端属性只是第一道轻量提示，不是防线本身。
