disableRemotePlayback 不是防投屏开关，仅为浏览器提示：Chrome/Edge 隐藏投屏图标但系统级投屏仍可绕过，Safari 仅影响 AirPlay 按钮可见性，Firefox 完全忽略；真正防护需服务端动态鉴权、HLS 加密、响应头限制及 iframe 防嵌套。
单纯在 <video></video> 标签里加 disableRemotePlayback，不能构成防投屏屏障——它只是个提示，不是锁。
为什么 disableRemotePlayback 不是“防投屏开关”
这个属性本质是向浏览器发一个“请勿启用投屏”的信号，而非执行策略：
- Chrome/Edge 会隐藏地址栏投屏图标、禁用右键菜单里的 Chromecast 选项，但用户仍可通过系统级投屏（如 Windows 的“连接到无线显示器”）绕过
- Safari 自 iOS 15.4 起支持 AirPlay 禁用提示，但仅影响 AirPlay 按钮可见性；用户手动打开控制中心仍可投
- Firefox 完全忽略该属性，设了也白设
- 它对 macOS 屏幕录制、Android 无线投屏协议（Miracast）、手机拍摄投屏画面等零防护能力
controlslist="noremoteplayback" 是更稳妥的写法
相比单独用 disableRemotePlayback，controlslist 是组合式 UI 控制，兼容性更好、意图更明确：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 必须以空格分隔关键字，不能带引号或等号：
controlslist="noremoteplayback nodownload nofullscreen" -
noremoteplayback在 Chrome/Safari 中实际效果比disableRemotePlayback更稳定（尤其在移动端 WebView） - 搭配
nodownload可隐藏下载按钮，避免用户误点后拿到明文 MP4 链接 - 注意：Safari 对
controlslist支持较晚（macOS 13+/iOS 16.4+），旧版本会直接忽略整段属性
真正起作用的防投屏，得靠服务端和播放逻辑协同
前端属性只能“劝阻”，拦截动作必须发生在请求链路上：
立即学习“前端免费学习笔记（深入）”；
- 所有视频请求走后端代理接口（如
/api/video/stream?id=xxx），不暴露原始 S3 或 CDN 地址 - 响应头中设置
Access-Control-Allow-Origin: https://your-edu-site.com，并禁用Access-Control-Allow-Credentials: true（避免跨域携带 Cookie） - 校验请求中的动态 Token：含用户 ID、设备指纹哈希、时间戳和 HMAC 签名，5 分钟内失效
- 监听
webkitbeginfullscreen和enterpictureinpicture事件，触发video.pause()并弹出提示：“检测到非授权播放环境，请在当前页面观看” - 关键课程视频启用 HLS + AES-128 加密，密钥由后端按 session 动态下发，不硬编码在 JS 或 HTML 中
最容易被忽略的一点：即使你把所有前端属性都设对了，只要视频资源响应头没设 X-Frame-Options: DENY 或 Content-Security-Policy: frame-ancestors 'none'，别人就能用 iframe 套住你的视频页，再在自己的页面里调用投屏 API —— 这类漏洞在教育平台的第三方嵌入课件场景中高频出现。
