controlslist="noremoteplayback" 仅隐藏投屏按钮，不阻止投屏；真正有效的是 disableRemotePlayback 布尔属性，需直接写在 <video> 标签上或 JS 动态设置（加载前），但仍是建议性限制，且 Firefox 不支持、iOS Safari 支持有限。
controlslist="noremoteplayback" 不能防止投屏，只能隐藏按钮
它只是告诉浏览器“别在控件栏里显示 AirPlay / Chromecast 按钮”，不改变视频能否被投屏的本质能力。用户仍可通过地址栏投屏图标、系统级菜单（如 macOS 的菜单栏 AirPlay、Windows 的 Win + K）或第三方工具发起投屏——controlslist 对这些完全无效。
真正起作用的是 disableRemotePlayback 布尔属性
这是目前唯一被 Chromium 和较新 Safari 支持的原生禁用提示机制，但它仍是“建议”而非强制：
-
disableRemotePlayback必须直接写在<video>标签上，不能加等号或引号：<video controls disableRemotePlayback> - JavaScript 动态设置也有效，但必须在视频加载完成前执行：
video.disableRemotePlayback = true - iOS Safari 自 15.4 起部分支持，但仅限 AirPlay；旧版 iOS 完全忽略
- Firefox 当前不支持该属性，设了也白设
为什么加了还是能投屏？常见原因
不是代码写错了，而是场景没覆盖全：
- 页面有多个
<video>，只给其中一个加了disableRemotePlayback，其他未加的仍可被选中投屏 - 用了 Video.js、hls.js 等播放器，它们会动态创建新
<video>元素，原始标签上的属性不会继承过去 - 用户开启的是系统镜像/录屏（如 QuickTime、Xbox Game Bar），这类操作绕过所有 HTML 属性
- 视频已开始播放后再设置
disableRemotePlayback，部分浏览器 UI 不会刷新，按钮仍可点
真正防不住的地方，得换思路
前端属性对物理拍摄、抓包下载、屏幕录制毫无约束力。如果业务真有强保护需求：
立即学习“前端免费学习笔记（深入）”；
- 服务端必须做 Token 鉴权，且链接单次有效、绑定 UA/IP、带短时效
- 敏感内容优先走 HLS/DASH + AES-128 或 DRM（Widevine/FairPlay），并配置
outputProtection限制 HDCP 输出 - 避免依赖
controlslist或disableRemotePlayback做权限判断——它们连“是否显示按钮”都不能跨浏览器保证
