分片加载是构建防投屏方案的必要基础，通过JS主动fetch、解密、推入MediaSource实现细粒度控制，使浏览器无法获取原始URL、投屏协议无法接管、右键保存失效。
分片加载本身不防投屏，但它是构建真正防投屏方案的必要基础——只有把视频切成可控单元，才能配合解密、鉴权、动态密钥等机制做细粒度控制。
为什么直接用 src 指向 MP4/HLS 就没法防投屏
浏览器拿到一个完整 URL（比如 https://cdn.example.com/video.mp4），它会：① 自动发起 Range 请求拉取元数据和帧；② 把整个流交给底层媒体栈；③ 同时开放投屏入口（AirPlay/Chromecast）和右键保存。此时你连“哪一帧正在播”都干预不了，更别说拦截或混淆。
分片加载的核心价值，是把控制权从浏览器手里拿回来——换成 JS 主动 fetch 每一片、校验、解密、再喂给 MediaSource。
- MP4 分片需服务端预切为固定大小（如 512KB）并 AES-GCM 加密，每片带独立
iv和认证标签 - HLS 分片（
.ts）不能只加密 payload，必须加密整个 TS 包头 + 负载，否则播放器解析失败 - 关键点：分片清单（m3u8 或 JSON 索引）本身也要动态生成、带时效 Token，不能静态暴露
MediaSource + Web Crypto 是当前最可行的前端防投屏链路
这不是“加个属性就完事”的方案，而是一整套协作流程：服务端分片加密 → 前端按需拉取 → 内存中逐片解密 → 推入 SourceBuffer 播放。投屏功能在此链路中天然失效，因为：
立即学习“前端免费学习笔记（深入）”；
- 浏览器根本看不到原始视频 URL，
video.src指向的是blob:地址 - 投屏协议（如 DIAL、RAOP）无法接管由 JS 构建的 MediaSource 流
- 右键菜单里“保存视频”选项灰掉——没有可导出的 media resource
示例关键逻辑：
const mediaSource = new MediaSource();
video.src = URL.createObjectURL(mediaSource);
mediaSource.addEventListener('sourceopen', () => {
const sb = mediaSource.addSourceBuffer('video/mp4; codecs="avc1.42E01E"');
// fetch 第一片加密数据 → 解密 → appendBuffer
fetch(`/api/chunk?id=123&token=${genToken()}`)
.then(r => r.arrayBuffer())
.then(buf => window.crypto.subtle.decrypt({ name: 'AES-GCM', iv }, key, buf))
.then(decrypted => sb.appendBuffer(decrypted));
});
容易被忽略的三个硬伤
这套方案能拦住普通用户和自动化工具，但别误以为它“绝对安全”：
- 系统级录屏（macOS QuickTime、Windows Game Bar）完全不受影响，JS 层无权干预
- 如果解密密钥硬编码在 JS 里或通过简单算法生成，逆向成本极低；必须依赖服务端动态下发短期有效的密钥
-
disableRemotePlayback属性仍要加上——它虽不强制，但在 Chrome/Safari 中能隐藏投屏图标，减少用户主动触发意愿
真正的防护水位线不在前端代码行数，而在服务端是否做了 Token 绑定 UA/IP、是否限制单次播放会话的分片请求频次、是否对异常高频 fetch 做熔断。分片只是把门打开了一条缝，后面全是服务端在守。
