HTML视频无法可靠防投屏，因浏览器无API检测投屏状态；所谓“调试状态”仅指开发者工具开关，与投屏无关；真正影响投屏的是视频元素属性、用户手势触发及DRM策略。
HTML 视频无法可靠防投屏，检测“页面调试状态”对阻止投屏完全无效——浏览器没有提供任何 API 能判断当前页面是否被投屏、镜像或录屏，所谓“调试状态”只是开发者工具打开与否，和视频输出目标毫无关系。
为什么 devtools.open 或 isDevToolsOpen 不存在
浏览器从未暴露过类似 devtools.open 的属性或事件。网上流传的“通过控制台打印时间差/监听 debugger / 检测 __REACT_DEVTOOLS_GLOBAL_HOOK__”等方法，全是误判：
- 它们只能推测“开发者工具是否曾被打开过”，且极易被绕过（如清空控制台、禁用脚本、换浏览器）
- 即使 DevTools 关闭，投屏、AirPlay、Chromecast、OBS 录屏仍照常工作，视频帧照样被采集
- Chrome 120+、Edge 122+ 已明确移除所有历史探测技巧的可行性，
performance.memory等字段也已废弃或返回 null
document.hidden 和 pageVisibility 只反映标签页活跃度，不反映投屏
这两个状态只说明当前 tab 是否在前台可见，跟视频是否被镜像到电视/投影仪上无关：
- 用户开启 AirPlay 后，页面仍在前台，
document.hidden === false，但视频已输出到外部设备 - Android 投屏（如 Samsung Smart View）下，页面可能保持 focus，
visibilitychange根本不触发 - 部分 iOS Safari 在投屏时会短暂触发
visibilitychange，但无规律、不可靠，且无法区分是切后台还是投屏
真正影响投屏的只有播放上下文与媒体策略
能否被投屏，取决于三个硬性条件，和“是否在调试”无关：
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
- 视频必须使用原生
元素，且未设置disablePictureInPicture或webkit-playsinline等限制属性 - 播放必须由用户手势触发（
click/touchstart），否则 Safari/iOS 会直接禁用 AirPlay 按钮 - 若视频启用了 DRM（如 Widevine、FairPlay），投屏行为由 CDM（Content Decryption Module）策略控制，前端 JS 完全无权干预或感知
如果你真想降低被录屏/投屏风险，只能做减法
没有检测手段，只有约束手段。以下操作能实际提高门槛，但无法杜绝：
- 对敏感视频启用
encrypted-media+ FairPlay（iOS/macOS）或 Widevine（Android/Chrome），投屏时若接收端不支持对应 CDM，将黑屏或报错 - 禁用原生控件：
，并隐藏 AirPlay 按钮：CSS 中加video::-webkit-media-controls-overlay-play-button { display: none; }（仅限 Safari） - 避免使用
MediaStream或canvas.captureStream()输出，这类流极易被系统级录屏工具捕获 - 服务端可结合 UA + IP + 设备指纹识别异常播放行为（如同一账号多端同时播放），但这属于业务风控，不是前端防护
别再找“检测调试”的方案了——那是个伪需求。投屏和录屏是操作系统/硬件层能力，前端运行在沙箱里，连进程都看不到，更别说判断屏幕去了哪儿。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
