disableRemotePlayback仅是向浏览器发出禁用投屏的UI提示，不加密、不鉴权、不阻止网络抓包，对源文件无任何保护作用；真正防护需依赖服务端动态Token校验与代理分发。
disableRemotePlayback 只是提示，不保护源文件
设置 disableRemotePlayback 属性对视频源文件毫无防护作用——它既不改变请求头、不加密传输、也不阻止网络抓包。浏览器仍会照常发起 GET 请求获取 .mp4、.m3u8 或 .ts 资源，这些 URL 一旦被复制，就能在任意设备上直接播放或下载。
该属性仅向 Chromium 内核（Chrome/Edge）和较新 Safari 发出“请勿显示投屏入口”的 UI 提示，Firefox 完全忽略，Android WebView 行为不可靠。用户打开开发者工具 → Network 面板 → 过滤 media，几秒内就能拿到全部分片地址。
真正影响源文件访问的是服务端鉴权逻辑
防投屏和防源文件泄露是两个独立问题，但共用同一道防线：**请求到达资源前是否被校验**。关键不在 HTML 标签怎么写，而在你代理视频流的后端接口如何设计。
- 不要直接把 S3 预签名 URL 塞进
src或source—— 即使加了disableRemotePlayback，URL 仍会在 Elements 面板中明文可见 - 必须走自有 API 代理，例如
/api/video/stream?videoId=abc&token=xyz，每次请求都校验：token时效性、绑定的userId和userAgentHash、IP 是否突变 - 响应头强制设置
Access-Control-Allow-Origin: https://your-app.com且禁止通配符，避免被第三方 iframe 盗用 - CDN 层（如 CloudFront）开启 Origin Access Identity（OAI），确保 S3 桶策略只允许该 OAI 访问，彻底屏蔽直链
controlsList="noremoteplayback" 是冗余操作
controlsList="noremoteplayback" 和 disableRemotePlayback 功能重叠，且前者兼容性更差（Safari 不支持，移动端多数无效）。二者都不影响源文件暴露风险，反而可能因写法错误导致失效：
立即学习“前端免费学习笔记（深入）”；
常见错误包括：disableRemotePlayback="true"（应为无值布尔属性）、controlsList="noremoteplayback nodownload" 中空格未转义导致解析失败、在动态创建 video 元素后未重新 attach 到 DOM 就调用 load()。
如果业务真需降低投屏概率，优先做的是监听 webkitbeginfullscreen 事件并在触发时暂停播放 + 上报，而不是依赖这个属性本身。
源文件安全的底线：没有“不可见 URL”，只有“不可复用 URL”
所谓“保护源文件”，本质是让拿到的链接在 5 分钟后失效、换设备就 403、甚至同一设备二次请求都需新 token。这要求：
- 前端生成 token 时必须包含强熵值（如
HMAC-SHA256(videoId + userId + timestamp + secretKey)） - 服务端校验时必须拒绝重复 token（用 Redis 记录已用 token 的
videoId:timestamp组合，TTL 设为略长于有效期） - 避免在日志、监控、错误堆栈中打印完整 token 或原始 URL，防止侧信道泄露
任何把逻辑放在前端、靠混淆或隐藏 HTML 属性来“保护源文件”的做法，都在自欺欺人。源文件是否安全，只取决于那个 GET /api/video/stream 请求背后，有没有一道无法绕过的门禁。
