HTML视频防投屏基本没用，它仅隐藏部分浏览器UI入口，无法阻止系统级投屏或直接访问资源；真正有效的是服务端鉴权、禁用电视接收功能和阻断局域网设备发现。
HTML视频防投屏基本没用，它既不阻止投屏行为，也不保护内容本身——只是让部分浏览器“假装看不见”投屏入口。
disableRemotePlayback 属性到底做了什么
它只是一个提示信号，不是策略开关。Chrome/Edge 会据此隐藏地址栏 Cast 图标和右键菜单里的“投屏”项；Safari（iOS 15.4+）仅对 AirPlay 做有限响应；Firefox 完全忽略。写成 disableRemotePlayback="true" 或 videoEl.setAttribute('disableRemotePlayback', '') 都无效，必须是布尔属性形式：<video controls disableremoteplayback></video>。
常见错误现象包括：Cast 按钮依然可点、右键仍有投屏选项、安卓 WebView 或微信内置浏览器完全无反应。
- 它不影响系统级投屏（如 macOS 全局 AirPlay 菜单、Windows “连接到无线显示器”）
- 不阻止用户手动点击浏览器 Cast 扩展投整个标签页
- 对集成 Google Cast SDK 的页面完全无效
- 无法干预电视端直接访问
.m3u8地址的行为
controlslist="noremoteplayback" 的兼容性更广但同样不强制
这个属性比 disableRemotePlayback 更早被支持，在 Chrome、Edge 和部分新版 Safari 中都能隐藏 UI 入口。写法必须是空格分隔的指令列表：<video controls controlslist="nodownload noremoteplayback"></video>，不能加引号或赋值。
但它只作用于播放器控件层，对以下场景毫无影响：
- 用户已建立投屏会话后刷新页面，投屏仍在继续
- 微信/QQ 浏览器（X5/XWeb 内核）大概率忽略该属性
- 第三方播放器 SDK 封装了原生
<video></video>，属性被隔离 - 未设置
crossorigin="anonymous"时，后续 Canvas 水印逻辑会因 CORS 失败
真正起作用的环节在服务端和网络层
所有投屏协议（Cast/Miracast/DLNA）都依赖局域网设备发现（mDNS/SSDP/UDP 广播）。前端加再多属性，只要电视能“看见”你的设备并拉到资源，就拦不住。
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
有效手段只有三类：
- 禁用电视端接收能力：小米电视关“无线投屏”，海信关“多屏互动”，LG webOS 关“允许设备连接”
- 切断资源访问路径：用动态 token 鉴权 URL 替代明文
src，.m3u8接口需登录态校验，token 绑定 UA/IP 且 5 分钟过期 - 阻断网络发现：拔网线、关 Wi-Fi、或把播放页部署在非局域网环境（如内网隔离 VLAN）
前端唯一能做的，是配合后端增加失败点：比如删掉 window.MediaSource 让 hls.js 失效，或用 CSP 的 media-src 限制分片加载来源。
为什么测试时总感觉“好像拦住了”
因为你在 Chrome 桌面版里点了几次 Cast 图标变灰，就误以为生效了。但换个环境立刻失效：iOS Safari 用户仍可通过控制中心 AirPlay、安卓电视用 DLNA 扫描到你的 HTTP 服务、甚至直接在地址栏输 http://192.168.x.x:8080/video.mp4 就播。
最容易被忽略的是：一旦视频 URL 明文暴露（比如写死在 HTML 里），用户复制后用 VLC 一粘贴就播；或者抓包拿到 .m3u8，用 ffmpeg 直接下载全部 .ts 片段——这些操作跟 disableRemotePlayback 是否存在毫无关系。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
