必须用controlslist="noremoteplayback"禁投屏，oncontextmenu无效；该属性需配合controls使用，大小写严格；服务端需校验User-Agent、Referer及签名URL才能真正防护。
video 标签加 controlslist="noremoteplayback" 才能禁投屏
仅靠 oncontextmenu="return false" 拦右键，对投屏完全无效——它只隐藏浏览器菜单，不影响系统级投屏入口。真正阻止 Chromecast/AirPlay 等远程播放，必须用 HTML5 原生属性 controlslist。
这个属性是唯一被 Chrome、Edge、Safari（macOS/iOS）和 Firefox（有限支持）承认的投屏控制开关：
-
controlslist="noremoteplayback"：禁用所有远程播放按钮（包括视频控件里的投屏图标） -
controlslist="nodownload noremoteplayback"：同时关下载和投屏（推荐组合） - 不写
controls属性时，controlslist无效；必须搭配controls使用 - 注意大小写：
noremoteplayback不是no-remote-playback或noRemotePlayback
为什么 oncontextmenu 对投屏没用
用户点视频右下角「⋯」→ 选「投屏」，这个操作不触发 contextmenu 事件。它是原生媒体控件的一部分，由浏览器渲染层直接处理，JS 无权拦截。
常见误解场景：
立即学习“前端免费学习笔记（深入）”；
- 给
<video></video>加了oncontextmenu="return false"，但投屏按钮仍在 → 正常，该属性只拦鼠标右键菜单，不拦控件按钮 - 用 JS 移除
<source></source>的src后再动态注入 → 仍可投屏，因为投屏走的是 Media Session API，跟源地址是否可见无关 - 在移动端长按视频 → 触发系统级分享菜单，
contextmenu完全不触发，更谈不上影响投屏
配合 service worker 或 referrer 校验才真防投屏
前端限制只是表层。真实投屏行为会发起一个独立的 media 请求（User-Agent 常含 "Cast" 或 "AirPlay"），服务端可据此做拦截：
- 检查请求头
User-Agent是否含Cast、AirPlay、GoogleTV - 验证
Referer是否来自合法域名，空 Referer 或非预期来源直接 403 - 对视频流启用短期签名 URL（如 5 分钟过期），避免投屏设备缓存后离线重放
- 不要依赖
document.visibilityState或页面焦点判断——投屏时页面可能仍在前台，但媒体流已分离
移动端 Safari 的 AirPlay 行为特别难控
iOS/macOS 上，即使加了 controlslist="noremoteplayback"，用户仍可通过系统级控制中心点击 AirPlay 图标投屏，且该操作完全绕过网页 DOM 和 JS。
目前无标准 API 可禁用，只能弱化：
- 确保视频
playsinline属性存在，强制内联播放（减少全屏触发 AirPlay 的概率） - 移除
webkit-playsinline以外的冗余属性，避免触发旧版 Safari 的兼容逻辑 - 不使用
webkit-video-play-button等私有伪元素自定义控件——它们可能意外暴露投屏入口 - 如果业务允许，用
<canvas></canvas>+ MediaSource API 渲染视频帧：彻底脱离原生<video></video>控件链，AirPlay 图标自然消失（但代价是失去硬件解码、字幕、音轨切换等能力）
