canvas capturestream() 返回 mediastream，不可直接转为 readablestream；二者本质不同：前者是封装的媒体轨道，后者是字节级可管道化流；需通过 mediarecorder、getimagedata 或 blob.stream() 等显式转换。
Canvas 视频流捕获（captureStream()）和 ReadableStream 是两类完全不同的数据通道，**它们不直接互通，也不能“打通”为同一数据源**。混淆常源于对“流”一词的泛化理解——前者是浏览器封装的、面向媒体传输的同步视频轨道（MediaStream），后者是底层字节级、可管道化处理的数据流（如 fetch 响应、WebRTC DataChannel 或 TransformStream）。识别二者差异，关键看目标用途和数据形态。
看数据本质：MediaStream ≠ ReadableStream
Canvas.captureStream() 返回的是一个 MediaStream 对象，内含 VideoTrack（可能还有 AudioTrack），它：
- 不暴露原始字节或帧缓冲区；
- 无法用 .getReader() 获取 reader；
- 不能 pipeTo() 到 WritableStream；
- 只能传给 MediaRecorder、RTCPeerConnection.addTrack()、<video srcobject></video> 等媒体消费端。
而 ReadableStream（如 fetch('/video.mp4').then(r => r.body)）提供的是：
- 可分块读取的 Uint8Array 字节流；
- 支持 .pipeThrough(new TextDecoderStream()) 等转换；
- 适合解析容器结构（如 MP4 的 MOOV）、提取元数据或自定义解码。
看使用场景：何时需要“桥接”，以及怎么桥接
真正需要“关联”两者的典型场景，是想对 Canvas 上实时渲染的画面做离线分析或存档级处理，比如：
- 把 captureStream 输出的视频流，转成 MP4 文件并上传（此时需 MediaRecorder → Blob → FileReader → ReadableStream）；
- 在 Web Worker 中接收 canvas 绘制的帧，用 OffscreenCanvas + ImageBitmap + createImageBitmap 转为纹理，再通过 WebGL 提取像素 → 转为 Uint8Array → 构造 ReadableStream 供 WASM 解码器消费；
- 用 canvas 捕获 video 元素画面后，调用 ctx.getImageData() 获取 RGBA 数组，再手动打包为二进制 chunk，用 new ReadableStream({ pull: ... }) 构造模拟流。
注意：这些都不是“打通”，而是主动转换路径，中间必有显式的数据拷贝或格式重封装。
常见误判点：哪些看似“打通”其实只是巧合
以下情况容易被误认为“Canvas 流已接入 ReadableStream”：
- 使用 MediaRecorder 录制 captureStream 并监听 dataavailable 事件 → 得到的是 Blob，不是 ReadableStream（需 Blob.stream() 显式转换）；
- 将 canvas.toBlob() 结果转为 stream → 这是单帧快照，与 captureStream 的持续视频流无关；
- 在 Service Worker 中拦截 video.src 请求并返回自定义 ReadableStream → 它绕过了 canvas，和 captureStream 没关系。
判断是否走对路：三秒自查法
遇到“想把 canvas 视频变成可读流”需求时，快速确认：
- ✅ 你要的是“每帧像素数组用于 JS 计算”？→ 用 requestAnimationFrame + getImageData()，别碰 captureStream；
- ✅ 你要的是“低延迟推流到远端”？→ 直接用 captureStream().getVideoTracks()[0] 加入 RTCPeerConnection；
- ✅ 你要的是“把实时画面存成文件再上传”？→ 用 MediaRecorder，录完用 blob.stream()；
- ❌ 试图 canvas.captureStream().pipeThrough(...)？→ 语法报错，MediaStream 没 pipeThrough 方法。
