禁用投屏需同时设置controlslist="noremoteplayback"与controls属性，并动态注入带签名的一次性视频URL，配合MediaSource API分片加载，从源头阻断可投媒体源。
video 标签里写死 src 就等于主动交出投屏入口
只要 <video src="https://xxx.com/video.mp4"> 这种写法存在，Chrome、Edge、vivo 浏览器等都可能自动识别并启用投屏按钮——哪怕你没加 controlslist="noremoteplayback"。这不是 bug，是浏览器对“可播放媒体资源”的默认行为。用户点投屏时，浏览器直接把该 URL 推送给电视端解码，全程不经过你的业务逻辑。
controlslist="noremoteplayback" 是唯一 HTML 层面有效开关
这个属性必须写在 <video> 标签上，且仅对支持该标准的浏览器生效（Chrome 78+、Edge 79+、vivo 浏览器 12.5+）。它不阻止视频播放，只切断浏览器自动注册投屏能力的链路。
-
controlslist必须和controls同时出现才可靠；单独用会降级为无控件模式 - 不能写成
control-list或controlList，大小写和连字符必须严格匹配 - 若同时设
controlslist="noremoteplayback nodownload"，两个功能互不干扰，但需注意：禁用投屏 ≠ 禁用下载，nodownload只隐藏按钮，不防 Network 面板抓包
真正防投屏要从源头掐断可访问 URL
即使加了 noremoteplayback，如果视频地址本身是公开可直连的（比如 S3 公开桶、CDN 未鉴权路径），用户仍可通过开发者工具复制 <source> 的 src，再手动粘贴到支持投屏的 App（如 VLC for Android）中触发投屏。所以关键不是“藏按钮”，而是“不让 URL 存在”：
- 前端永远不硬编码任何视频地址，
<source>的src必须由 JS 动态注入，且值来自后端带签名的一次性代理地址（如/stream?vid=abc&token=xyz&ts=1734701220） - 该代理接口需校验
Referer、User-Agent、签名时效与用户身份，过期或校验失败即返回 403 - 避免使用 HLS 的
.m3u8作为最终交付格式——它本质是文本索引文件，极易被爬取并用于第三方投屏
MediaSource API 是目前最抗投屏的加载方式
当视频流完全通过 fetch + MediaSource + SourceBuffer.appendBuffer() 注入时，Network 面板只看到一连串带签名的分片请求（如 /chunk?id=abc&seq=12&sig=def），没有任何完整视频 URL 可供提取。投屏功能因找不到“可投媒体源”而自然失效。
立即学习“前端免费学习笔记（深入）”；
但要注意：MediaSource 不支持所有格式，MP4 必须是 fragmented MP4（fMP4），H.264/AVC 编码需含 moov 在前；服务端需支持 Range 请求，并按需返回 206 Partial Content。
别指望前端拦截能挡住投屏——oncontextmenu="return false" 或 user-select: none 对投屏零影响。真正的防护锚点只在服务端 URL 生成逻辑和传输层控制。一旦 URL 落到用户设备内存里，就已失去控制权。
