disableremoteplayback必须作为布尔属性直接写在video标签中，不赋值、不加引号，如；disableremoteplayback="true"等写法均无效。
disableRemotePlayback 必须作为布尔属性原生写在 <video></video> 标签中，不赋值、不加引号、不写 =true，否则完全失效。
disableRemotePlayback 属性怎么写才有效？
它不是配置项，是 HTML 布尔属性，只存在“有”或“没有”两种状态。浏览器只认这种写法：
<video controls disableremoteplayback><source src="video.mp4" type="video/mp4"></source></video>
以下全是无效写法，会被忽略：
disableRemotePlayback="true"disableRemotePlayback="disabled"-
disableRemotePlayback=""（空字符串） - 用 JS 动态设置
video.disableRemotePlayback = true（部分浏览器不响应）
controlslist="noremoteplayback" 是什么？和 disableRemotePlayback 冲突吗？
不是冲突，而是互补：前者是提示浏览器禁投屏，后者是告诉浏览器“别显示投屏控件”。controlslist="noremoteplayback" 实际上只是隐藏右键菜单里的 AirPlay / Cast 选项和地址栏投屏图标，不改变底层行为。
两者可共存，推荐组合使用：
<video controls disableremoteplayback controlslist="noremoteplayback"><source src="video.mp4" type="video/mp4"></source></video>
注意：controlslist 中的 noremoteplayback 在 Safari 和 Chrome 有效，在 Firefox 里被完全忽略，且对系统级投屏（如 macOS 系统菜单中的“AirPlay 显示器”）无任何限制。
为什么加了 disableRemotePlayback 还能投屏？
因为该属性本质是“建议”，不是策略 enforcement。常见失效场景包括：
- 用户手动点击 Chrome 地址栏右侧的 Cast 图标（投的是整个标签页，绕过 video 层）
- 使用 iOS 系统级 AirPlay 手势（从屏幕底部上滑调出控制中心 → 点击 AirPlay）
- Android 设备通过系统“无线显示”投射桌面
- 网页本身未启用 HTTPS（Chrome 会降级处理该属性）
- 视频源是 HLS 或 DASH 流，但播放器用 hls.js / dash.js 自行接管了
<video></video>，原生属性未透传到实际播放元素
真正需要防投屏时，不能只靠 HTML 属性
如果业务涉及付费课程、内部培训视频等敏感内容，仅靠 disableRemotePlayback 和 controlslist 几乎起不到实质防护作用。必须配合后端手段：
- 服务端校验 Referer + Token（带时间戳和 UA 绑定）
- 动态生成短期有效的 HLS/DASH playlist URL，过期即 403
- 对 DRM 受保护内容，在 license server 配置
outputProtection要求 HDCP，限制非可信输出设备 - 前端监听
webkitbeginfullscreen或enterpictureinpicture，触发暂停或水印增强
HTML 层的投屏控制，永远只是第一道轻量提示——它能拦住随手点投屏的新手，拦不住有意识截取的人。真正的防线得落在网络请求、密钥分发和播放器生命周期管理上。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
