disableRemotePlayback必须作为布尔属性直接写在video标签中，不赋值、不加引号；写成disableRemotePlayback="true"等格式将被浏览器忽略，且Firefox完全不支持。
disableRemotePlayback 属性必须写成布尔属性，不能赋值
很多开发者误写成 disableRemotePlayback="true" 或 disableRemotePlayback="disabled"，这会导致浏览器完全忽略该属性。它只接受“存在即启用”的语义，正确写法是直接写 disableRemotePlayback（无等号、无引号、无值）。
这个属性仅向浏览器发出提示，不构成强制策略。Chrome/Edge 会据此隐藏投屏图标和右键菜单中的 AirPlay/Chromecast 选项；Safari 自 iOS 15.4 起支持 AirPlay 禁用提示；Firefox 完全不识别，设了也无效。
常见错误现象包括：用户仍能从地址栏点击投屏按钮、iOS 上长按视频仍唤出 AirPlay 弹窗——这通常是因为属性未正确声明，或浏览器版本过低不支持。
controlslist="noremoteplayback" 是冗余且无效的
controlslist 支持 nodownload、nofullscreen 等参数，但 noremoteplayback 并不在规范中。W3C 标准和 Chromium 实现均未定义该关键字，写上去既不报错也不生效。
真正起作用的只有原生 disableRemotePlayback 属性。若同时写了 controlslist="noremoteplayback" 和 disableRemotePlayback，前者纯属噪音，还可能误导后续维护者以为它有作用。
注意：controlslist 的所有参数都只影响 UI 层可见性，不改变底层行为。即使隐藏了投屏入口，用户仍可通过系统级快捷键（如 macOS 的 AirPlay 菜单栏图标）发起投屏。
禁投屏不能替代内容保护，必须配合服务端鉴权
前端设置 disableRemotePlayback 后，用户依然可以：
- 用手机拍摄投屏画面（物理盗录）
- 开启系统录屏（macOS QuickTime、Windows Xbox Game Bar）
- 抓包提取
src或分片 URL 后本地下载（若后端未做 Token 验证）
所以，防投屏只是表层动作。关键防护点在服务端：
- 视频流必须走自有代理接口（如
/stream?videoId=abc&token=xyz），而非直连 S3 或 CDN 域名 - Token 需绑定
userId+userAgent+IP+ 时间戳，并限制 5–15 分钟有效期 - 响应头需设置
X-Frame-Options: DENY和Access-Control-Allow-Origin: https://your-site.com，防止 iframe 套嵌或跨域请求
监听投屏相关事件可辅助检测异常行为
虽然无法阻止投屏，但可以感知并响应。Chrome 和 Safari 支持以下事件：
-
webkitbeginfullscreen：用户点击全屏按钮时触发（注意不是投屏，但常被误用） -
enterpictureinpicture：进入画中画时触发 -
webkitpresentationmodechanged：Safari 中投屏状态变更时触发（需检查event.presentationMode）
示例逻辑：监听到 enterpictureinpicture 后，暂停播放并弹出提示“当前内容不支持画中画”，再调用 document.exitPictureInPicture() 尝试退出（部分浏览器允许）。
但要注意：这些事件并非所有平台都可靠触发，且无法捕获系统级投屏（如 macOS 控制中心 AirPlay）。它们更适合用于埋点统计或轻量干预，不能作为安全防线。
最易被忽略的一点：disableRemotePlayback 在动态设置（如 JS 中 video.disableRemotePlayback = true）时，Chrome 95+ 才开始支持，旧版浏览器会静默失败。务必在 HTML 初始化时就声明该属性，不要依赖运行时 JS 注入。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
