disableRemotePlayback 是 HTML 中唯一影响投屏的原生属性，仅作提示而非强制防护，必须以布尔属性形式书写且初始化时写入HTML，无法阻止系统录屏、物理拍摄或网络抓包等行为。
disableRemotePlayback 是目前 HTML 中唯一能影响投屏行为的原生属性，但它不是“防投屏”，只是向浏览器发一个“请不要投”的提示——Chrome/Edge 会响应，Safari（iOS 15.4+）仅对 AirPlay 有弱提示，Firefox 完全无视。真想降低投屏风险，得组合策略，而不是指望单个属性。
为什么 disableRemotePlayback 必须写成布尔属性而非带值形式
浏览器只认 disableRemotePlayback 这个属性名是否存在，不解析它的值。写成 disableRemotePlayback="true" 或 disableRemotePlayback="disabled" 会被当成普通字符串属性，直接忽略。
- ✅ 正确：
<video controls disableremoteplayback></video> - ❌ 错误：
<video controls disableremoteplayback="true"></video>、<video controls disableremoteplayback="1"></video> - ⚠️ 动态设置（如
videoEl.setAttribute('disableRemotePlayback', 'true')）在部分 Chrome 版本中不生效，建议初始化时就写死在 HTML 里
仅靠 disableRemotePlayback 无法阻止哪些行为
它不参与 DRM 授权流程，也不限制系统级能力，以下操作完全不受影响：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用户用 macOS QuickTime 或 Windows Xbox Game Bar 录制整个浏览器窗口
- 手机拍摄电视投屏画面（物理盗录）
- 通过 DevTools 的 Network 面板抓取
.m3u8或.ts分片 URL，再用 ffmpeg 下载 - 禁用
controls后，用户仍可通过右键“检查元素”找到src并另存为
轻量级组合方案：服务端鉴权 + 前端感知 + 控制粒度收窄
不引入 DRM 也能提升门槛，关键在于让“一次有效播放”和“可复用资源”解耦：
立即学习“前端免费学习笔记（深入）”；
- 服务端返回视频 URL 时，附带短期有效的签名 Token（如 10 分钟过期），并绑定
Referer和User-Agent，防止 URL 被盗用 - 前端监听
webkitbeginfullscreen（Safari）或enterpictureinpicture（Chrome），触发时立即pause()并弹出提示：“该内容不支持全屏/画中画” - 配合
controlslist="nodownload nofullscreen"隐藏下载按钮和全屏入口，减少用户第一眼可操作项 - 避免使用
autoplay，防止页面加载即触发播放后被自动投屏（某些旧版 Cast 扩展会捕获 autoplay 标签页）
真正难防的是系统级镜像和物理拍摄——disableRemotePlayback 连这个边都碰不到。轻量方案的价值不在“绝对防住”，而在提高批量盗取成本、筛掉非目标用户、为后续升级 DRM 留出缓冲期。
