WebSocket无法原生封装为ReadableStream，因其事件驱动本质与pull-driven流机制冲突；强行桥接需手动适配并自行处理分帧、编码、错误等；而fetch和EventSource天然契合流式语义；更优方案是定义轻量StreamSource接口，由各传输层实现，兼顾抽象一致性与协议真实性。
不能直接用 ReadableStream 封装 WebSocket 接收端来实现“统一的流式元编程抽象”——这不是技术限制，而是协议本质冲突导致的设计不可行。
WebSocket 本身不提供 ReadableStream 接口
原生 WebSocket 对象（包括浏览器和 Node.js 的 ws、uWebSockets 等）在设计上是基于事件驱动的：靠 onmessage 或 addEventListener('message') 接收数据块。它没有 .body 属性，也不暴露 getReader() 方法，因此无法像 fetch() 响应那样自然接入 ReadableStream 生态。
你不能写 ws.response.body.getReader() —— 因为 ws 根本没有 response，更没有 body。
强行桥接需手动构造 ReadableStream
若坚持统一抽象，可行路径是：监听 message 事件，把每条消息（text/binary）推入一个自建的 ReadableStream 实例。这本质是“适配器模式”，不是封装：
- 需用
new ReadableStream({ pull(controller) { ... } })手动创建流 - 用
controller.enqueue()主动推送收到的消息 - 需自行处理分帧、粘包、编码（如 UTF-8 解码）、错误传播和关闭同步
- 无法复用
TransformStream管道做解密/解析/限流等，除非你把整个逻辑塞进pull中
为什么 EventSource 和 Fetch 更适合 ReadableStream 抽象
这两者天然契合流式语义：
-
fetch()返回Response，其body是标准ReadableStream -
EventSource虽是事件 API，但底层 HTTP 流响应可被包装为流（例如用new ReadableStream({ pull })拦截onmessage并 enqueue） - 它们都是单向、服务端主导、按 chunk 流式吐出的模型，与
ReadableStream的 pull-driven 机制对齐
而 WebSocket 是双向、全双工、消息粒度不固定（可发 text/binary/pong）、支持客户端随时主动发送的协议——它的抽象重心在“连接状态管理”和“消息路由”，不在“流控”。
更务实的统一抽象方案
与其硬套 ReadableStream，不如定义一个轻量接口，让不同传输层都实现它：
- 定义
interface StreamSource { start(): void; stop(): void; onChunk(chunk: Uint8Array | string): void; onError(err: any): void; } - 为
fetch + ReadableStream、EventSource、WebSocket各写一个实现类 - 上层业务只依赖
StreamSource，后续可自由替换传输方式
这样既保持抽象一致性，又不违背各协议的底层事实。流式元编程的关键是行为契约，不是类型强制。
