一、录制安全与隐私：HTTPS强制要求、用户授权机制、录制内容加密、录制数据本地存储

说实话，WebRTC 的录制功能虽然强大，但安全这块要是没做好，那就是给自己挖坑。我见过不少开发者，功能做完了，上线前被安全审计卡住，回头改代码改到崩溃。今天咱们就把这四块硬骨头啃下来。

1.1 HTTPS 强制要求——不是建议，是必须

WebRTC 的 getUserMedia 接口，在非安全上下文（也就是 HTTP）下根本不会工作。这不是浏览器故意刁难你，而是为了保护用户隐私。

我记得有一次帮朋友调试一个本地项目，他死活拿不到摄像头权限。折腾了半天，发现他用的就是 http://localhost。嗯，localhost 是个例外，但生产环境必须上 HTTPS。

为什么会这样？说白了，如果允许 HTTP 页面访问摄像头，中间人攻击就能轻松偷拍你。浏览器厂商在这件事上态度非常强硬——我举双手赞成。

1.2 用户授权机制——别偷偷摸摸

用户授权这块，很多开发者容易犯一个错误：一进页面就弹权限请求。你想想看，用户刚打开你的页面，啥都没看到，先弹个「是否允许使用摄像头」，换你你点允许吗？

我个人习惯的做法是：

1. 先展示页面内容，让用户知道这个功能是干嘛的
2. 在用户点击「开始录制」按钮时，才触发权限请求
3. 如果用户拒绝了，给出友好的提示，而不是直接报错

我曾经在一个项目中遇到过用户反复拒绝权限的情况。后来加了一个引导页，用图文说明「我们需要摄像头来录制教学视频，不会上传到任何地方」，授权率从 40% 提升到了 85%。

1.3 录制内容加密——别让数据裸奔

录制好的视频数据，在传输和存储过程中必须加密。这里分两种情况：

场景	加密方式	说明
实时传输	SRTP / DTLS	WebRTC 原生支持，默认开启
本地存储	AES-256 / Web Crypto API	需要手动实现

实时传输这块，WebRTC 已经帮我们做好了。但本地存储很多人会忽略——录好的视频直接扔进 IndexedDB 或者本地文件系统，明文存储。这要是被恶意脚本扫到了，后果你懂的。

我建议的做法是：录制完成后，用 Web Crypto API 对 blob 进行加密，再存到本地。解密的时候才拿出来用。

// 使用 Web Crypto API 加密录制数据
async function encryptBlob(blob, key) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const algorithm = { name: 'AES-GCM', iv };
  
  const encrypted = await crypto.subtle.encrypt(
    algorithm,
    key,
    await blob.arrayBuffer()
  );
  
  return { encrypted, iv };
}

1.4 录制数据本地存储——能本地就别上传

很多应用一拿到录制数据就往服务器传。其实大部分场景下，用户只是想本地保存，或者剪辑后分享。你想想看，把用户的视频传到你的服务器上，出了数据泄露谁负责？

我个人推荐的做法是：

• 优先本地存储：用 IndexedDB 或 File System Access API 存到用户本地
• 按需上传：只有用户明确点击「分享」或「保存到云端」时才上传
• 上传前加密：如果必须上传，先加密再传，服务端只存密文

我曾经做过一个在线面试录制工具，一开始设计成录制完自动上传。结果用户投诉说「我只是想自己看看表现，不想让公司知道」。后来改成本地存储 + 手动上传，用户满意度直接翻倍。

知识体系总览

下面这张图把今天讲的内容串起来了。你可以看到，安全不是某一个环节的事，而是贯穿整个录制流程的。

好了，这一章的内容就到这里。记住一句话：安全不是功能，是底线。底线守住了，用户才敢用你的产品。