MediaStream Recording API 提供了在浏览器中直接录制音视频流的能力，其核心对象 MediaRecorder 通过 start() 方法可以按指定时间片（timeSlice）将媒体数据切割成多个 Blob 切片。每个切片会通过 ondataavailable 事件抛出，开发者通常将这些切片暂存到数组，待录制结束再合并成一个完整文件。然而，此过程的类型定义在 TypeScript 官方 lib.dom.d.ts 中仅仅是 BlobEvent，返回的 data 属性被标注为 Blob | null，没有对切片特征做进一步细化。这导致在接收、存储、上传这些切片时，大量的类型断言或 as Blob 写法被滥用，不仅掩盖了空值检查，还可能让后续对切片内容的读取（比如转 ArrayBuffer）出现意料之外的类型错误。
要完善这套类型，我们必须先理解 dataavailable 事件的触发时机。当调用 mediaRecorder.start(timeslice) 后，浏览器内部会按照 timeslice 毫秒定期生成一个 Blob 切片并触发事件；当调用 stop() 时，最后一个未满 timeslice 的切片也会作为最终事件抛出。因此，所有切片都是 Blob 的一种，但最后一片通常较小且标志着录制结束。基于这个特点，我们可以通过扩展事件类型和创建专用存储接口，让 TypeScript 精确地捕捉到切片数量和结尾标记，从而避免空切片或重复合并等问题。
从 BlobEvent 到自定义切片事件类型
TypeScript 内置的 BlobEvent 接口定义非常简单：它继承自 Event，并包含一个只读属性 data: Blob | null。在实际录制中，只要 MediaRecorder 状态正常，data 几乎不会为 null。但这种“可能为空”的类型标注会让后续处理十分啰嗦——每处理一个切片都要进行非空断言或条件判断。我们可以通过声明一个更精确的子类型来解决。
一种方式是利用 TypeScript 的声明合并（declaration merging），直接为 BlobEvent 添加一个明确非空的 data 属性。但更推荐的做法是定义一个专用的切片事件接口，避免污染全局类型：
interface SliceEvent extends Event {
readonly data: Blob; // 强制非空
}
这样，在给 MediaRecorder 安装事件监听时，我们可以手动将事件对象转换为 SliceEvent，但更好的方案是封装一个录制器类，在内部完成类型收窄。比如，在事件回调中利用类型守卫检查 event instanceof BlobEvent && event.data !== null，然后将该切片连同时间戳等信息包装成自定义的 RecordSlice 结构：
interface RecordSlice {
data: Blob;
timestamp: number;
isLast: boolean; // 标记是否为结束切片
}
这个 RecordSlice 不仅去掉了可空性，还增加了录制阶段的元数据。isLast 标记非常重要，它可以帮助合并逻辑识别何时可以安全地组装最终文件。在 onstop 事件的处理中，我们将最后一个切片标记为 true，而正常时间片触发的切片标记为 false。这样一来，任何消费切片的函数（比如上传或本地缓存）都能通过类型系统明确得知当前是中间切片还是最终切片，无需依赖隐式的数组位置判断。
构建类型安全的切片存储与合并器
有了 RecordSlice 的定义，下一步便是设计一个泛型存储容器，它不仅保存切片，还约束合并操作的输入输出类型。常见的错误是把所有切片简单放进 Blob[] 数组，然后用 new Blob(chunks) 合并，但这样会丢失“最后一个切片”的语义。我们可以定义一个类型安全的 SliceCollector 类：
class SliceCollector {
private slices: RecordSlice[] = [];
addSlice(slice: RecordSlice): void {
this.slices.push(slice);
}
getFinalBlob(mimeType: string): Blob {
// 确保最后一个切片被正确标记
const lastSlice = this.slices[this.slices.length - 1];
if (!lastSlice || !lastSlice.isLast) {
throw new Error('录制未正确结束，无法生成最终 Blob');
}
return new Blob(this.slices.map(s => s.data), { type: mimeType });
}
}
借助这个收集器，我们不再零散地操作数组，而是通过方法调用的方式注入切片。TypeScript 会强制检查 addSlice 传入的参数必须是 RecordSlice 类型，从而防止混入裸 Blob 或 null 值。此外，getFinalBlob 在内部检验结束标记，避免因过早调用 stop() 逻辑而合成不完整的媒体文件。
如果录制场景需要支持不同的 MIME 类型（比如 video/webm 或 audio/webm），我们可以把收集器做成泛型，让其携带 MIME 类型的字面量信息：
class TypedSliceCollector<T extends string> {
private slices: RecordSlice[] = [];
addSlice(slice: RecordSlice): void {
this.slices.push(slice);
}
getFinalBlob(): Blob {
const last = this.slices[this.slices.length - 1];
if (!last?.isLast) throw new Error('结束切片缺失');
return new Blob(this.slices.map(s => s.data), { type: 'video/webm' as T });
}
}
虽然泛型参数在运行时会被擦除，但它可以配合工厂函数在编译期锁定输出类型，帮助下游代码按特定 MIME 处理数据。例如，当我们在 React 状态中存储 Blob 时，可以通过 TypedSliceCollector<'audio/ogg'> 编译期标记，让后续的 URL.createObjectURL 调用更受约束。
处理切片数据读取与类型转换陷阱
许多开发者拿到 Blob 切片后会立刻调用 blob.arrayBuffer() 或使用 FileReader 将其转换为 ArrayBuffer 再做进一步处理，比如音频波形分析或传输。此时类型安全问题往往出现在异步操作后的变量使用上。一个典型的错误是：将切片数组映射为 Promise<ArrayBuffer> 数组，然后用 Promise.all 等待，最后直接将这些 ArrayBuffer 连接起来创建新的 Blob。然而，直接拼接 ArrayBuffer 并不会保留原始编码的媒体容器结构，生成的文件通常无法正常播放。正确的做法是始终基于原始 Blob 切片进行合成，而不是深入到二进制层面拼接。
在类型层面，我们可以为需要读取切片内容的场景定义专门的转换函数，并利用 TypeScript 区分「只读」和「可合并」的切片。例如：
interface ReadableSlice {
readonly data: Blob;
readAsArrayBuffer(): Promise<ArrayBuffer>;
}
class SliceReader implements ReadableSlice {
constructor(public readonly data: Blob) {}
readAsArrayBuffer(): Promise<ArrayBuffer> {
return this.data.arrayBuffer();
}
}
这样一来，任何需要读取切片内部数据的模块都只能通过 readAsArrayBuffer() 进行，而不能直接操作底层 Blob 的内部结构。这个限制由 TypeScript 的只读属性保证，有效防止了无意的修改或类型混用。同时，合并逻辑依然使用原始的 RecordSlice.data 数组，两者互不干扰。当团队中的成员试图将 ArrayBuffer 结果重新塞回切片数组时，编译器便会报错，因为类型不匹配。
总结来看，为 MediaStream Recording API 分段录制定义切片类型，核心在于：第一，用自定义接口替代宽泛的 BlobEvent，消除可空性和语义模糊；第二，通过专用收集器或泛型容器封装切片数组，强制检查结束标记；第三，隔离数据读取与合成路径，利用类型系统防止二进制层面的误操作。这套类型定义投入很低，却能在持续迭代的录制功能中显著减少运行时调试时间，值得在每个基于 TypeScript 的媒体项目中采用。
TypeScriptMedia_Stream_Recording_API切片类型修改时间：2026-08-12 11:37:45