disableRemotePlayback 仅起提示作用，非强制策略：Chrome/Edge 中隐藏投屏入口，Safari 弱提示 AirPlay，Firefox 完全忽略；无法阻止系统级投屏或物理盗录，须配合 DRM 等后端防护。
disableRemotePlayback 属性到底管不管用
它只起提示作用，不是强制策略。Chrome 和 Edge 中设了 disableRemotePlayback 后，地址栏投屏图标会变灰、右键菜单里 AirPlay/Chromecast 选项会消失；但 Safari（iOS 15.4+ / macOS 12.3+）仅对 AirPlay 有弱提示，Firefox 完全忽略。更关键的是：用户仍可手动打开系统级投屏（如 Windows 的“连接到无线显示器”），该属性对此毫无约束力。
controlslist="noremoteplayback" 是错的写法
controlslist 不支持 noremoteplayback 这个值——这是常见误传。浏览器会直接忽略该参数，等同于没写。正确做法是单独使用布尔属性 disableRemotePlayback，且必须不带等号、不带引号：
<video controls disableRemotePlayback> <source src="secure.mp4" type="video/mp4"> </video>
⚠️ 错误写法包括：disableRemotePlayback="true"、disableRemotePlayback="disabled"、controlslist="noremoteplayback"，这些都会导致失效。
禁用投屏 ≠ 防止内容泄露
即使 disableRemotePlayback 生效，以下行为依然畅通无阻：
立即学习“前端免费学习笔记（深入）”；
- 用户用手机拍摄投屏画面（物理盗录）
- 开启系统录屏（macOS QuickTime、Windows Xbox Game Bar）
- 在 DevTools 的 Network 面板中抓取
.mp4或.m3u8URL 直接下载 - 通过
chrome://dumps/或内存 dump 提取解密后的帧数据（尤其在未启用 DRM 时）
真正需要防投屏的场景（如金融培训、内部课程），必须配合服务端 Token 鉴权 + HLS AES-128 分片加密 + Widevine/FairPlay DRM，否则前端任何属性都只是聊胜于无。
监听投屏事件比隐藏按钮更实际
比起依赖不可靠的 HTML 属性，监听 enterpictureinpicture 或 webkitbeginfullscreen 更能及时响应异常行为：
video.addEventListener('enterpictureinpicture', () => {
if (!isAuthorizedForPiP()) {
video.exitPictureInPicture().catch(() => {});
alert('画中画功能受限');
}
});
注意：video.exitPictureInPicture() 必须由用户手势触发才可能成功，纯脚本调用在多数浏览器中会被静默拒绝。所以重点应放在「检测 + 告警 + 上报」，而非强行拦截。
最常被忽略的一点：所有前端投屏控制都建立在“用户不主动调试”的前提下。一旦打开 DevTools，disableRemotePlayback 就形同虚设——它连阻止右键“检查元素”都做不到。
