disableremoteplayback是w3c标准布尔属性，存在即生效，不可赋值；正确写法为或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"></source></video>- JS 动态设置：
videoElement.disableRemotePlayback = true（必须在video元素已挂载 DOM 后执行）
注意：动态设置在 iOS Safari 上基本无效；Chrome/Edge 支持稳定，Firefox 完全不支持该属性。
为什么加了还是能点投屏按钮？常见三类漏点
最常被忽略的不是写法，而是上下文环境：
- 页面里有多个
<video></video>，只给其中一个加了disableRemotePlayback，其他没加的仍会出现在 Chrome 地址栏投屏菜单中 - 用了 Video.js、hls.js 等播放器，它们会销毁原始
<video></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"></video>，但 Safari 会无视后者，Chrome 下也无需叠加。
移动端（尤其 iOS）要禁投屏，光靠 disableRemotePlayback 不够
iOS Safari 对 disableRemotePlayback 的支持从 iOS 15.4 才开始，且行为不稳定；即使设了，AirPlay 按钮有时仍会闪现。真正有效的组合是：
- 同时声明
playsinline和webkit-playsinline，减少触发 AirPlay 的机会 - 配合
disablePictureInPicture防止画中画干扰 - 必要时加兜底：
x-webkit-airplay="deny"（Safari 私有属性，虽非标准但实测有效） - 服务端必须做鉴权：视频 URL 带短期 token，抓包复制链接后几秒即失效
前端属性只是第一道门，真正的防线永远在服务端——disableRemotePlayback 设得再对，也拦不住用户录屏或拍屏。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
