disableRemotePlayback仅是提示性布尔属性，非强制策略；Chrome/Edge支持良好，Safari自iOS 15.4起部分支持，Firefox完全忽略，且无法阻止系统录屏或物理盗录。
disableRemotePlayback 属性本身不会“失效”，它从来就不是强制开关——只是个提示。如果你发现加了该属性后仍能投屏，不是代码写错了，而是浏览器没照做，或者用户绕过了它。
为什么 disableRemotePlayback 看起来没用
这个布尔属性只在部分浏览器中起作用，且仅影响 Chromecast/AirPlay 的 UI 可见性与初始投屏入口，不阻断底层协议或系统级行为：
- Chrome / Edge：设为
disableRemotePlayback（无等号、无值）后，地址栏 Cast 图标会置灰，右键菜单里“投射到设备”选项消失 - Safari：iOS 15.4+ 和 macOS 12.3+ 才开始响应，但仅对 AirPlay 菜单生效，且某些机型仍可从控制中心强行投
- Firefox：完全忽略该属性，设了也白设
- Android WebView / 小程序：行为混乱，有些版本直接跳过解析，有些则在初始化后又被 JS 动态覆盖
disableRemotePlayback 的正确写法和常见错误
必须作为原生布尔属性直接写在 <video></video> 标签上，不能带值，也不能用字符串赋值：
- ✅ 正确：
<video disableremoteplayback></video> - ❌ 错误：
<video disableremoteplayback="true"></video>（会被当普通字符串属性处理） - ❌ 错误：
<video disableremoteplayback="disabled"></video>（同上，无效） - ❌ 错误：通过 JS 动态设置
video.disableRemotePlayback = true（多数浏览器不支持运行时生效）
比前端属性更关键的三个落地点
真正降低投屏风险，得从服务端、播放器行为、输出策略三处下手，而不是只盯着 HTML 属性：
立即学习“前端免费学习笔记（深入）”；
- 服务端校验播放请求：用 JWT Token 绑定设备指纹（
User-Agent+IP+screen.width哈希），单次有效、10 分钟过期 - 监听投屏相关事件并干预：监听
webkitbeginfullscreen（Safari 全屏）、enterpictureinpicture（画中画）、cast.framework.CastContext.SESSION_STATE_CHANGED（Cast SDK），触发暂停或弹窗警告 - DRM 输出保护配置：若已接入 Widevine/FairPlay，License Server 必须启用
outputProtection策略，例如要求 HDCP 2.2，这样投屏设备若不支持就会拒绝解密帧数据
最容易被忽略的一点：哪怕你把 disableRemotePlayback、controlslist="noremoteplayback"、crossorigin="anonymous" 全加上，只要视频 URL 被抓包拿到，用户就能用 VLC 或 ffplay 直接拉流——前端一切控制，都挡不住一个能访问网络资源的终端。防投屏不是加个属性的事，是鉴权链、播放器行为、输出通道三者共同约束的结果。
