html视频无法真正防投屏，所谓“防投屏”依赖服务端drm、协议限制（如https强制）、设备识别等后端策略，前端属性如disablepictureinpicture或controlslist均无效。
HTML 视频本身无法主动“防投屏”——所谓“防投屏”实际是靠版权策略、协议限制和播放器行为间接实现的，所有声称“加个属性就能禁投”的方案都不可靠。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
为什么 <video></video> 标签加 disablePictureInPicture 或 controlsList="nodownload" 无效
这些属性只影响浏览器内置控件行为，对投屏完全无约束力：
- disablePictureInPicture 仅禁用画中画，不影响 Chrome Cast 按钮或系统级投屏
- controlsList="nodownload" 不阻止用户通过 Cast 按钮投整个标签页
- iOS Safari 无视大部分 controlsList 值，Android Chrome 对其支持也不一致
- 所有这些属性在 Miracast / AirPlay / DLNA 场景下均无作用——它们压根不走浏览器控制逻辑
navigator.mediaDevices.getUserMedia 失败是否影响防投屏
不影响。这是两个完全无关的机制：
- getUserMedia 控制的是**摄像头/麦克风采集权限**，用于 WebRTC 或拍照等场景
- 投屏行为由浏览器 UI（如 Chrome 右上角 Cast 按钮）或系统服务（AirPlay 菜单、Miracast 发现）触发，不依赖媒体设备 API
- 常见误判：看到控制台报 NotAllowedError 就以为“投屏被拦”，其实只是用户没给摄像头授权，和投屏功能毫无关系
真正能干扰投屏的三个技术点
以下操作可能让部分投屏路径失效，但都有明确局限性，不能当作可靠防护：
- 使用 localhost 或 http:// 协议：Chrome Cast SDK 强制要求 HTTPS，http:// 页面连 cast.framework.CastContext.getInstance() 都会静默失败
- 在 iframe 中嵌入视频且设 sandbox="allow-scripts"：若未显式加 allow-top-navigation-by-user-activation，Cast SDK 初始化可能被拦截
- 主动调用 document.exitPictureInPicture() 并监听 leavepictureinpicture：仅对画中画有效，对 Cast / AirPlay 无感知
- 关键限制：以上任意操作都无法阻止用户截取屏幕后重新编码推流，或用硬件采集卡录屏
版权方实际采用的防投屏手段
真正起效的不是前端代码，而是服务端与协议层协同：
- HLS 流中插入 #EXT-X-DISCONTINUITY-SEQUENCE + DRM（如 FairPlay、Widevine），使电视端解密失败而黑屏
- WebRTC 信令中不向非授信设备（如未知 IP 的 Chromecast）提供 SDP offer
- 服务端识别 User-Agent 或设备指纹，对投屏类 UA（如 Chromecast、AppleCoreMedia）直接返回 403 或空 m3u8
- 注意：这些策略全部依赖服务端判断，前端 JavaScript 无法绕过或模拟
最常被忽略的一点：哪怕你做了所有前端限制，只要视频资源 URL 是公开可访问的，用户就能用 VLC、ffplay 或自写脚本拉流——所谓“防投屏”，本质是防普通用户，不是防有工具链的人。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
