必须用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 无权拦截。

常见误解场景：

HTML Text Extract

从HTML页面（URL、文件或标准输入）中提取主体内容文本，去除导航、页脚、广告和模板文本。可直接传递给readability_check或其他文本工具。

下载

• 给 加了 oncontextmenu="return false"，但投屏按钮仍在 → 正常，该属性只拦鼠标右键菜单，不拦控件按钮
• 用 JS 移除 的 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 等私有伪元素自定义控件——它们可能意外暴露投屏入口
• 如果业务允许，用 + MediaSource API 渲染视频帧：彻底脱离原生 控件链，AirPlay 图标自然消失（但代价是失去硬件解码、字幕、音轨切换等能力）

真正的投屏防护不在 HTML 属性里，而在服务端对 media 请求的识别与响应策略。前端做的所有事，只是让普通用户“找不到按钮”，而不是让技术用户“无法投屏”。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！