HTML视频无法真正防投屏，所有措施仅阻断浏览器可访问流地址或干扰自动发现机制；controls和disablePictureInPicture对Chrome Cast等无效；前端不可信，必须依赖服务端动态token签名+Referer校验。
HTML 视频无法真正“防投屏”，只能限制常见投屏路径；所有所谓“防投屏”措施，本质都是阻断浏览器可访问的流地址或干扰自动发现机制，而非加密或硬件级拦截。
为什么controls和disablePictureInPicture拦不住投屏
原生 的 controls 属性只控制是否显示内置控件，不影响底层媒体资源可访问性；disablePictureInPicture 仅禁用画中画（PiP），对 Chrome Cast、DLNA、AirPlay 等完全无效。用户只要能拿到视频 URL（哪怕藏在 JS 里），就能用 curl、ffmpeg 或第三方工具拉流——浏览器本身不提供 DRM 级别保护。
- Chrome 地址栏输入
chrome://dino后按 Ctrl+Shift+M 可打开媒体面板，直接看到所有正在加载的.m3u8、.ts、.mp4请求 - 即使你用
fetch()+URL.createObjectURL()动态生成 blob URL，DevTools → Network → Media 标签页仍能捕获解码前的原始响应体 -
webkit-playsinline和x5-video-player-type="h5"这类微信/QQ 内置浏览器私有属性，只影响全屏行为，不改变资源暴露面
Referrer-Policy 和 Cross-Origin-Resource-Policy 能挡什么
这两个响应头只能阻止其他站点通过 直接嵌播，对同域页面内播放、或用户手动复制 URL 后用 VLC/ffplay 拉取毫无作用。
Convert Markdown To HTML And PDF - Markdown和HTML、PDF互转
下载
实现 Markdown↔ HTML 互转，支持导出 PDF，用于用户请求的文档格式转换。
-
Referrer-Policy: no-referrer-when-downgrade防止 referer 泄露，但不影响资源本身可访问 -
Cross-Origin-Resource-Policy: same-origin会让跨域 iframe 无法加载你的视频，但用户打开你自己的网页照样能右键“检查元素”找到地址 - 真正起效的组合是：
Content-Security-Policy: media-src 'self'+ 后端校验Referer头 + 动态 token 签名 URL（如/video/abc123.mp4?t=1734716400&s=xxxx），且 token 5 分钟过期
服务端动态 Token + Referer 校验是最实用的防线
前端永远不可信，防投屏必须靠服务端拦截。核心逻辑：每个视频请求必须携带有效签名，且签名绑定当前页面域名 + 时间戳 + 用户 session ID（如有）。
- 不要用固定密钥硬编码在 JS 里生成 token，密钥必须存在后端，前端只传参由后端拼接签发
- token 过期时间建议 ≤ 300 秒，避免被截获后长期复用；同时需支持刷新机制（如播放中触发
onseeking时预取新 token） - 若视频源是 HLS，务必对每个
.ts片段都做独立 token 校验，不能只校验.m3u8—— 否则攻击者可直接遍历 ts 索引 - Nginx 示例配置片段：
if ($args !~ "t=[0-9]+&s=[a-f0-9]{32}") { return 403; }，配合 Lua 模块做时间/签名双重验证
真要强约束，就得放弃纯 HTML5 方案
如果业务场景要求“绝对不可投”，比如医疗影像、金融培训视频，就必须脱离浏览器原生 ，改用 WebAssembly 解码器（如 ffmpeg.wasm）+ Canvas 渲染，或接入商业 DRM（Widevine、FairPlay）方案。
- WebAssembly 方案：视频流经 fetch 加密传输，JS 解密后喂给 wasm ffmpeg 解码，像素逐帧绘制到
—— 此时 DevTools 里看不到任何媒体资源 URL，但性能损耗大、移动端发热明显 - Widevine 要求 HTTPS + Chrome/Edge + 支持硬件 DRM 的设备，且需 Google 认证密钥服务器，个人或小团队基本无法落地
- 最常被忽略的一点：即便上了 Widevine，用户仍可用采集卡录屏——所谓“防投屏”，从来不是防所有录制，只是抬高非授权分发门槛
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
