disableRemotePlayback 必须作为布尔属性直接写为 disableRemotePlayback，不带等号和值；写成 disableRemotePlayback="true" 无效；Chrome/Edge 72+/79+ 支持并隐藏投屏入口，Safari 自 macOS 12.3/iOS 15.4 起仅对 AirPlay 有提示作用，Firefox 完全不支持。
video 标签里怎么写 disableRemotePlayback 才生效
必须直接写成布尔属性，不带等号、不赋值，否则浏览器会忽略：disableRemotePlayback。写成 disableRemotePlayback="true" 或 disableRemotePlayback="disabled" 都是无效的。
常见错误是把它当普通 HTML 属性用，结果右键菜单里的投屏选项照常出现。Chrome 和 Edge 72+/79+ 能识别并隐藏投屏入口；Safari 自 macOS Monterey 12.3 / iOS 15.4 起支持，但仅对 AirPlay 有提示作用；Firefox 完全不响应该属性。
- 正确写法：
<video controls disableRemotePlayback></video></li> <li>动态设置可用 JS：<code>videoElement.disableRemotePlayback = true
，但部分浏览器（如旧版 Safari）初始化后修改可能不触发 UI 更新 - 它只影响投屏按钮和
mediaSession.setRemotePlaybackState()等 API，不阻止系统级录屏或物理拍摄
controlslist="nodownload noremoteplayback" 的实际效果
controlslist 是提示性属性，不是开关。它只在 controls 存在时起作用，且仅建议浏览器隐藏对应按钮——浏览器有权无视。
目前只有 Chrome、Edge、Opera 对 nodownload 和 noremoteplayback 支持较稳定；Safari 仅部分支持 noremoteplayback；Firefox 完全忽略整个 controlslist 属性。
立即学习“前端免费学习笔记（深入）”；
-
nodownload只能隐藏视频控件里的下载图标，无法禁用右键菜单中的「视频另存为」 -
noremoteplayback和disableRemotePlayback功能重叠，但前者属于controlslist体系，后者是独立布尔属性，推荐优先用后者 - 移动端（尤其 iOS）对
nofullscreen等值支持极弱，双击仍可全屏，不要依赖
为什么禁右键 oncontextmenu 还是拦不住下载
单纯绑定 document.oncontextmenu = () => false 或给 <video> 加 oncontextmenu="return false"，只能阻止页面级右键菜单，但浏览器原生视频上下文菜单（如 Chrome 的“另存为视频”）由 UA 样式控制，JS 无法拦截。
更麻烦的是：用户打开 DevTools → Network 面板 → 找到 .mp4 或 .m3u8 请求 → 右键 Copy link address → 粘贴到新标签页，照样能下载。这个行为完全绕过前端所有限制。
- 禁右键最多防小白用户误操作，对懂技术的人毫无约束力
- 如果 video src 是带时效签名的 URL（如
?token=xxx&expires=1721767320），复制链接后过期就失效，这才是真正有效的防线 - 想彻底规避，得配合服务端 Referer 校验、User-Agent 绑定、单次 token 等策略
真正降低下载/投屏风险的组合手段
前端属性只是表层提示，要形成有效防护，必须前后端协同。单独靠 disableRemotePlayback 或 controlslist 本质是“礼貌请求”，而非技术强制。
容易被忽略的关键点在于：所有前端控制都运行在用户可控环境中。哪怕你用 MSE 加密分片、监听 webkitbeginfullscreen 并暂停播放，只要用户开抓包工具、换 UA、或用录屏软件，内容依然暴露。
- DRM（Widevine/FairPlay）才是生产环境底线，它让解密密钥不出设备，且 license server 可配置
outputProtection强制 HDCP - 服务端返回视频流时，应禁用
Accept-Ranges头，避免范围请求被用于分段下载 - 敏感内容播放阶段，可动态调用
videoElement.src = ""清空 src，再通过 blob URL + MSE 注入，让 network 面板看不到原始地址
