disableRemotePlayback仅提示浏览器禁用投屏，不约束HLS/DASH分片请求；真正防护需CSP connect-src限制+服务端实时鉴权分片URL。
video.disableRemotePlayback 只提示，不保护分片请求
disableRemotePlayback 是 <video> 标签的布尔属性，它仅向浏览器发出“不希望投屏”的信号，对 HLS/DASH 分片（.m3u8、.ts、.mp4、.mpd）的网络请求毫无约束力。分片加载由 JavaScript 播放器（如 hls.js、dash.js）通过 fetch 或 XMLHttpRequest 发起，走的是 connect-src 策略，不是 media-src —— 所以哪怕你写了 disableRemotePlayback，分片照样能被截、能被缓存、能被转发。
真正拦截分片请求靠 CSP 的 connect-src + 服务端鉴权
分片 URL 是否可被外部调用，取决于两个环节是否闭环：
- 前端必须配置严格的
Content-Security-Policy头：connect-src 'self' https://cdn.yourdomain.com，禁止任何未声明域名发起 fetch/XHR 请求；漏掉 CDN 子域或用了https://*.yourdomain.com而没校验二级路径，都可能让分片暴露 - 服务端对每个分片请求做实时校验：检查
Authorization头（JWT）、Referer（需配合Referrer-Policy: strict-origin-when-cross-origin）、IP/UA 绑定、Token 时效（建议 ≤15 分钟），且密钥不硬编码在前端 JS 中 - 若用 HLS，
.m3u8清单本身也得受鉴权保护——不能返回明文.ts路径，应返回带签名的动态地址（如chunk-123.ts?sig=abc&exp=1730000000）
hls.js/dash.js 动态加载时，分片 URL 构造逻辑必须混淆+隔离
播放器初始化后，分片地址常由 JS 动态拼接。此时容易踩坑：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 别把解密密钥或基础 URL 写死在源码里，用 WebAssembly 模块或 Service Worker 拦截并重写请求更稳妥
- 避免使用
hls.config.xhrSetup直接注入 header，该函数体可能被调试器断点捕获；改用beforeRequest钩子 + 闭包封装 token 获取逻辑 - 关键路径（如
getFragmentUrl）做代码混淆（Terser 启用mangle和compress），但注意保留hls.js必需的 hook 方法名 - Service Worker 中监听
fetch事件，对匹配/video/chunk/的请求强制校验 origin 和 referrer，不合法则返回 403
分片加密 ≠ 投屏防护，但它是必要前提
仅靠分片加密（如 HLS AES-128）无法阻止投屏，但它能防止分片被离线下载后直接播放。要注意：
立即学习“前端免费学习笔记（深入）”；
- AES 密钥必须由服务端按需下发，响应头设
Cache-Control: no-store，禁用所有中间缓存 - 密钥接口本身也要走鉴权，且返回的密钥有效期应短于分片 Token（例如 2 分钟），避免密钥泄露后长期有效
- 不要用 Clear Key 做生产环境防护，它等同于把密钥明文传给前端；Widevine/FairPlay 才具备输出保护能力（如限制 HDCP 版本）
- 浏览器 DevTools 的 Network 面板仍能看到加密后的
.ts文件，但内容是乱码——这已达成“防直接复用”目标，而非“防投屏”
connect-src 和后端 Token 校验必须同步生效，缺一不可；前端加了策略但服务端放行任意 referer，或服务端校验严格但前端 CSP 漏了 CDN 域名，都会让整套机制失效。 
