TypeScript中NodeJS.ReadableStream接口存在原因及继承疑问

• Node.js的流契约优先于类继承
  Node.js的可读流本质上是一套行为契约：只要对象实现了read()方法、触发data/end/error等事件，并且遵循可读流的状态管理逻辑，就可以被当作可读流使用。这种契约式的设计允许不通过继承Readable类来实现可读流——比如一些内置对象、第三方库的兼容实现，可能通过手动实现契约来模拟可读流行为，而非直接继承Readable。

• TypeScript的结构类型系统特性
  TypeScript采用结构类型（鸭子类型），判断类型兼容性只看对象的结构和行为，不看原型链或类继承关系。NodeJS.ReadableStream接口正是用来描述所有符合可读流契约的对象的类型，不管它是不是Readable类的实例。比如一个手动实现了on('data', ...)、pause()、resume()等方法的对象，哪怕原型链上没有Readable，只要结构匹配，就能被TypeScript识别为NodeJS.ReadableStream类型。

• 兼容多样化的流实现场景
  在实际开发中，存在不少非继承自Readable但符合可读流规范的对象：

  • 某些Node.js内置API返回的特殊对象，可能基于底层实现优化，没有直接继承Readable但完全遵循可读流契约；
  • 第三方库为了兼容不同环境（比如浏览器端模拟Node.js流），会手动实现NodeJS.ReadableStream接口的结构，而非依赖Readable类；
  • 测试场景中，开发者会创建模拟可读流的对象，仅实现必要的方法和事件，不需要完整继承Readable类。

简单来说，NodeJS.ReadableStream接口是为了覆盖所有符合可读流行为的对象，而Readable类只是其中一种实现方式——TypeScript需要用接口来描述这个更宽泛的契约，而不是局限于单一的类继承关系。

内容的提问来源于stack exchange，提问作者BlackGlory