真正能追踪视频泄露的是服务端日志与动态水印：每次播放请求须携带用户ID、设备指纹、时间戳；流地址需绑定上下文并记录日志；前端叠加含userId、timestamp、sessionToken哈希的随机偏移水印，每15秒刷新；盗录视频OCR水印后查日志即可定位源头。
disableRemotePlayback 属性不能追踪泄露来源
disableRemotePlayback 是一个纯提示型布尔属性，只影响浏览器 UI（比如隐藏 AirPlay / Cast 按钮），不产生任何日志、事件或网络请求。它既不触发回调，也不上报行为，更不会在服务端留下痕迹。设了 disableRemotePlayback 后用户仍可手动打开系统级投屏（如 macOS 的“屏幕镜像”菜单）、用手机拍摄、或通过录屏软件捕获画面——这些动作前端完全不可见。
真正能追踪泄露的只有服务端日志 + 动态水印
投屏本身不是网络请求，但“开始播放”一定是。要定位谁把视频传出去了，得从两个不可绕过的环节下手：
- 每次播放请求必须携带唯一上下文：用户 ID、设备指纹（
navigator.userAgent+screen.width+hardwareConcurrency组合哈希）、时间戳 - 后端生成的流地址（如 HLS
.m3u8或代理 URL）必须绑定该上下文，并记录进访问日志（含 IP、Referer、User-Agent、签名有效期） - 前端播放器需叠加动态水印：文字内容包含
userId、timestamp、sessionToken哈希片段，位置随机偏移、透明度 0.2–0.4，且每 15 秒刷新一次
当一段盗录视频流出，你只需截取任意一帧，OCR 提取水印文本，再查服务端日志中匹配该 userId + token + 时间窗口的请求记录，就能锁定原始播放设备和账号。
Chrome DevTools 里看到的 m3u8 地址不是泄露源头
很多人误以为抓到 Network 面板里的 .m3u8 URL 就等于找到泄露点，其实不然：
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
- 这个 URL 往往是带签名的临时地址（如
https://cdn.example.com/v/abc123.m3u8?sig=xyz&exp=1734739200），过期即失效 - 即使被转发，接收方若无对应
User-Agent或Referer头，CDN 或 Nginx 会直接返回 403 - 真正泄露的是“能反复生成这类 URL 的账号+权限”，而不是单个链接
所以日志里要重点标记高频请求、跨 IP 使用同一 token、或 UA 字符串异常（如含 curl、python-requests）的记录，而不是盯着某个 URL 是否被复制。
别依赖 onwebkitbeginfullscreen 这类事件
监听 webkitbeginfullscreen 或 enterpictureinpicture 看似能捕捉投屏意图，但问题很多：
- Safari 和 Firefox 不支持
webkitbeginfullscreen，Edge 已弃用 - 系统级投屏（如 Windows 无线显示、macOS 镜像）根本不会触发这些事件
- 用户禁用 JavaScript 后，监听完全失效
- 即使触发，你也只能暂停播放，无法知道是谁、在哪台设备上做的操作
这类前端钩子最多起提示作用（比如弹个“检测到全屏，请勿录屏”），对溯源毫无价值。真要防，就别让没水印、没鉴权的视频流离开你的服务端。
