disableremoteplayback是html5 video标签唯一原生支持的禁用远程投屏提示属性，必须以布尔形式直接写为，不可赋值；它仅向浏览器发出提示，非强制策略，chrome/edge支持良好，safari自ios 15.4起部分支持，firefox不支持，且无法阻止系统录屏或物理盗录。
disableRemotePlayback 属性怎么写才生效
直接写 disableRemotePlayback，不加等号、不赋值，否则浏览器会忽略它。这是唯一合法写法：
<video controls disableremoteplayback><source src="lesson.mp4" type="video/mp4"></source></video>
常见错误包括：disableRemotePlayback="true"、disableRemotePlayback="disabled"、甚至用 JS 动态设置 video.disableRemotePlayback = true —— 这些在 Chrome/Edge 中基本无效，Safari 更是完全不响应动态设置。
该属性仅向浏览器“提示”禁用投屏，不是指令。Chrome 和 Edge 会隐藏地址栏 Cast 图标和右键菜单里的“投射到设备”，但用户仍可手动打开整个标签页投屏；Safari 自 iOS 15.4 起对 AirPlay 有类似响应，Firefox 则完全无视。
controlslist="noremoteplayback" 是多余操作吗
是的，纯属重复。HTML 规范里 controlslist 的 noremoteplayback 参数，本质就是映射到 disableRemotePlayback 的布尔状态，两者作用完全重叠。写成这样：
<video controls controlslist="noremoteplayback"></video>
和只写 disableRemotePlayback 效果一样，且更冗余。更关键的是：这个参数在 Safari 和 Firefox 中同样不被识别，只有 Chromium 系浏览器部分支持，且行为不稳定（比如某些版本下只影响右键菜单，不影响 Cast 按钮）。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
别指望靠组合多个属性增强效果——controlslist="nodownload nofullscreen noremoteplayback" 并不会让投屏控制更牢，反而增加维护成本和兼容性盲区。
为什么设了 disableRemotePlayback 还能投屏成功
因为浏览器根本不强制执行。它只是个建议信号，底层是否响应、响应到哪一步，取决于：
- 浏览器内核版本（旧版 Chromium 可能未实现）
- 操作系统投屏协议栈（如 macOS 的 AirPlay、Windows 的 Miracast）是否绕过网页层直接捕获渲染输出
- 用户是否选择“投射此标签页”而非“投射此视频”——前者完全不受
disableRemotePlayback约束
尤其要注意：系统级录屏（QuickTime、Xbox Game Bar）、手机拍摄投屏画面、抓包提取 URL，这些行为 完全不受该属性影响。它连“阻止投屏”都做不到，更别说防录屏或防盗链。
真正能降低投屏风险的落地动作有哪些
前端单靠 HTML 属性无解，必须配合服务端与播放逻辑协同：
- 后端生成带时效签名的视频 URL（如
/v/abc123?t=1734685380&s=9f3a...），过期即 403，防止链接被复用 - 播放时监听
webkitbeginfullscreen或enterpictureinpicture事件，触发暂停 + 提示，至少做到“感知+干预” - 对高敏感内容启用 DRM（Widevine/FairPlay），并在 license server 配置
outputProtection策略，要求 HDCP 加密输出（这才能真正限制非授权投屏设备解码） - 避免在页面中暴露原始视频地址，改用 MSE + Blob URL 加载分片，让 DevTools Network 面板看不到完整 .mp4/.m3u8 路径
最常被忽略的一点：投屏能力依赖设备发现机制（如 mDNS），而现代企业网络常禁用多播，导致 Cast/AirPlay 根本不可见——这不是前端能解决的，得查防火墙和路由器设置。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
