disableRemotePlayback是W3C标准布尔属性，存在即生效，不可赋值；正确写法为<video disableRemotePlayback>或JS动态设置video.disableRemotePlayback = true，Chrome/Edge支持良好，iOS Safari自15.4起部分支持，Firefox不支持，且无法阻止系统镜像或录屏。
disableRemotePlayback 是布尔属性，不能写成 disableRemotePlayback="true"
这个属性只认“存在即生效”，写了就代表 true，写成 disableRemotePlayback="true" 或 disableRemotePlayback="disabled" 反而会被浏览器忽略——它不是 HTML 中常见的可赋值属性。
正确写法只有两种：
<video disableRemotePlayback controls><source src="a.mp4"></video>- JS 动态设置：
videoElement.disableRemotePlayback = true（必须在video元素已挂载 DOM 后执行）
注意：动态设置在 iOS Safari 上基本无效；Chrome/Edge 支持稳定，Firefox 完全不支持该属性。
为什么加了还是能点投屏按钮？常见三类漏点
最常被忽略的不是写法，而是上下文环境：
立即学习“前端免费学习笔记（深入）”；
- 页面里有多个
<video>，只给其中一个加了disableRemotePlayback，其他没加的仍会出现在 Chrome 地址栏投屏菜单中 - 用了 Video.js、hls.js 等播放器，它们会销毁原始
<video>并新建一个，原始标签上的属性不会继承过去，得等播放器实例 ready 后手动设player.tech().el().disableRemotePlayback = true - 用户用的是系统级镜像（如 macOS 的“屏幕镜像”或 Windows + K），这属于整屏采集，
disableRemotePlayback对它完全无约束力
controlslist="noremoteplayback" 和 disableRemotePlayback 有什么区别？
两者目标重叠但机制不同：
-
controlslist="noremoteplayback"是 UI 层提示，只影响控件栏里的 AirPlay/Chromecast 图标是否显示，且仅 Chromium 系列（Chrome/Edge）支持，Safari 和 Firefox 忽略 -
disableRemotePlayback是更底层的信号，影响地址栏投屏图标、右键菜单项、以及mediaSession.setRemotePlaybackState()等 API 行为 - 推荐优先用
disableRemotePlayback，它是 W3C 标准属性；controlslist只作补充，不能替代
二者可共存：<video controls disableRemotePlayback controlslist="noremoteplayback">，但 Safari 会无视后者，Chrome 下也无需叠加。
移动端（尤其 iOS）要禁投屏，光靠 disableRemotePlayback 不够
iOS Safari 对 disableRemotePlayback 的支持从 iOS 15.4 才开始，且行为不稳定；即使设了，AirPlay 按钮有时仍会闪现。真正有效的组合是：
- 同时声明
playsinline和webkit-playsinline，减少触发 AirPlay 的机会 - 配合
disablePictureInPicture防止画中画干扰 - 必要时加兜底：
x-webkit-airplay="deny"（Safari 私有属性，虽非标准但实测有效） - 服务端必须做鉴权：视频 URL 带短期 token，抓包复制链接后几秒即失效
前端属性只是第一道门，真正的防线永远在服务端——disableRemotePlayback 设得再对，也拦不住用户录屏或拍屏。
