单纯靠前端HTML属性无法防抓包和投屏；disableRemotePlayback仅是UI提示，真正有效的是服务端动态鉴权与短时效预签名URL。
单纯靠前端 HTML 属性无法防范抓包，更不能因此实现“防投屏”。disableRemotePlayback 只是 UI 提示，对抓包获取视频地址毫无拦截能力；真正能增加抓包难度的，是服务端动态鉴权与资源加载路径设计。
为什么抓包总能拿到视频地址
用户打开 DevTools → Network → Filter “media” 或 “mp4/m3u8/ts”，只要视频是明文写在 src 里、或由 JS 拼接后直接赋值，就必然暴露。常见失效点：
-
src是静态 URL：→ 直接右键复制地址用 VLC 播放 - HLS 地址硬编码在 JS 中：
hls.loadSource("https://cdn.example.com/playlist.m3u8?token=xxx")→ token 过期前可复用 - 未设
crossorigin="anonymous"，但后端又没配 CORS → 视频能播，Canvas 水印却因 CORS 被拒，白加一层
如何让抓包拿到的地址快速失效
关键不是“藏地址”，而是让地址一离开当前会话就作废。需前后端协同：
- 所有视频资源不直连 OSS/S3，统一走带鉴权的代理接口，如
/api/play?videoId=abc&ts=1730098200&sig=xxx - 签名（
sig）必须含不可预测因子：用户 ID + 时间戳（精确到秒）+ 随机 salt（服务端私有），且服务端校验时拒绝 5 分钟外的请求 - 代理接口返回 302 重定向到临时预签名 URL（AWS S3 presigned URL 或阿里云 STS Token URL），有效期严格控制在 60 秒内
- 若用 HLS，
.m3u8文件本身也必须由接口生成（而非静态文件），且其中每个.ts分片 URL 同样带短时效 token
前端加载方式影响抓包难度
直接赋值 video.src 是最易被截获的方式。更稳妥的做法是绕过 DOM 属性暴露：
- 用
fetch()拉取加密视频流 → 解密 → 构造Blob→URL.createObjectURL(blob)→ 赋给video.src，此时 Network 面板只看到加密 blob 请求，无原始 URL - 对 HLS，改用
hls.js的loader自定义逻辑，在每次请求.m3u8或.ts前动态注入 token，避免 token 出现在初始 JS 字符串中 - 禁用开发者工具可见的调试线索：移除所有含
videoUrl、playSource等命名的变量，混淆关键函数名（如getPlayToken→_a1b）
容易被忽略的致命漏洞点
很多团队做了 token 鉴权，仍被批量下载，问题常出在这些地方：
- token 校验逻辑写在前端 JS 里（比如用固定密钥本地算 sig），攻击者反编译后可完全模拟
- 同一个 token 被多个设备/浏览器复用，未绑定 UA 或 IP，导致一个 token 泄露，全公司账号都可播
- 未关闭 OSS/S3 的
ListObjects权限，攻击者用遍历前缀（?prefix=videos/2026/）直接列出全部视频 key - 错误认为
disableRemotePlayback能阻止抓包 —— 它连 network 面板都关不掉，只是让右键菜单少个选项而已
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
