Node.js中Readable流先触发close而非end事件是否异常？

我正在调试一段使用tar-fs的代码：

const tarFs = require('tar-fs');
const tarStream = tarFs.pack(process.cwd(), ['hundreds','of','files']);

该tarStream会被传递至azure-sdk-for-js的一个接收NodeJS.ReadableStream的函数中，该函数监听了data、error、end、close事件。

脚本偶尔会无限挂起，无法稳定复现，但多次运行后必然出现。观察到两种行为：

• 未挂起时：data事件触发后会正常触发end事件；
• 挂起时：data事件触发后仅触发close事件，end事件永不触发，且无error事件抛出。

疑问 #

1. 哪些情况会导致Readable流（尤其是tar-fs返回的PackStream）触发close事件？
2. end事件是否应始终在close前触发？先触发close是否一定意味着异常？

注：Node.js文档未说明close先于end触发是否代表异常。

1. 触发Readable流（含tar-fs PackStream）close事件的常见场景 #

• 底层资源被强制关闭：比如流关联的文件描述符被手动调用fs.close()关闭，或是操作系统因资源不足、权限问题强制回收了资源。
• 流被主动销毁：调用流的destroy()方法（无论是否传入错误），会直接触发close事件，若此时数据还未完全读取，end事件可能不会触发。
• 下游流中断触发连锁反应：如果tarStream被管道到其他可写流，下游流意外关闭触发close时，可能反向触发上游可读流的close事件。
• tar-fs内部异常静默处理：tar-fs打包文件时，若遇到无法读取的文件（比如文件在打包过程中被删除、权限不足），内部捕获异常但未向上抛出error事件，而是直接终止流并释放资源，这种情况也可能只触发close。

2. end与close的触发顺序及异常判定 #

• 正常流程下，end事件应当在close之前触发：end代表流的所有数据已完全读取并交付给消费者，close则代表流关联的所有底层资源已被释放。
• 先触发close大多属于异常场景，但并非绝对：
  • 这种情况通常意味着流的底层资源在数据未完全读取完成前就被释放，可能是资源被强制回收、流被主动销毁，或是依赖的外部资源（如文件）意外消失。
  • 极端合法场景极少：比如主动调用destroy()时，流已无待处理数据但end尚未触发，可能直接触发close，但这种情况非常罕见。

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