类：BenchmarksStream

🌐 Class: BenchmarksStream

BenchmarksStream 是一个对象模式的 <stream.Readable>。每条生命周期记录既会作为命名事件被发出，也会以 { type, data } 的形式在流中可用。

事件会按执行顺序发出：

🌐 The events are emitted in execution order:

• 'bench:plan'
• 'bench:start'
• 'bench:sample'
• 'bench:complete'
• 'bench:diagnostic'
• 'bench:summary'

命名事件的有效负载、可读记录以及基准完成值都是独立的快照。通过一种传递机制收到的值的更改不会影响通过其他机制收到的值。和其他<EventEmitter>事件一样，同一个命名事件的多个监听器会收到相同的事件负载。通过<SharedArrayBuffer>引用的内存仍然是共享的，遵循结构化克隆语义。

🌐 Named event payloads, readable records, and benchmark completion values are independent snapshots. Mutating a value received through one delivery mechanism does not change values received through the others. As with other <EventEmitter> events, multiple listeners for the same named event receive the same event payload. Memory referenced through a <SharedArrayBuffer> remains shared, following structured clone semantics.

一旦消费者开始读取，运行器会遵守流的对象模式高水位标记，并在消费者比生产者慢时在记录之间等待。这些等待发生在采样计时结束后，记录不会被丢弃。快照的创建和传输等待不计入基准超时。在可读消费开始之前，记录会累积在标准可读缓冲区中，并包含在 readableLength 中。这可以防止未读流和只使用命名事件的消费者产生死锁，但缓冲区可能会无限增长。不需要可读记录的仅命名事件消费者应调用 stream.resume() 来丢弃它们。销毁流会停止可读传输，但不会取消基准执行，因此基准完成的承诺仍会结算。自动调度的模块级运行会在内部清空其流。

🌐 Once a consumer starts reading, the runner honors the stream's object-mode high-water mark and waits between records when the consumer is slower than the producer. These waits occur after sample timing has ended, and records are not dropped. Snapshot creation and delivery waits are excluded from benchmark timeout accounting. Before readable consumption starts, records accumulate in the standard readable buffer and are included in readableLength. This keeps an unread stream and a consumer using only named events from deadlocking, but the buffer can grow without bound. A named-event-only consumer that does not need readable records should call stream.resume() to discard them. Destroying the stream stops readable delivery but does not cancel benchmark execution, so benchmark completion promises still settle. Automatically scheduled module-level runs drain their stream internally.

通过进程隔离，每个子进程发送的记录只有在父进程接受后才会收到确认。子进程在收到确认之前不会发送额外的记录，这样当报告程序比较慢时，进程间通信的传输就会被限制。

🌐 With process isolation, each record sent by a child is acknowledged only after the parent has accepted it. A child sends no additional record until it receives that acknowledgement, bounding the IPC relay when a reporter is slow.

每个基准范围的事件都包含 runId、fileRunId、entryFile、benchId、parentId 和 namePath。runId 和 fileRunId 是不透明的，并且在每次运行时都会变化。entryFile 标识导致声明的顶层基准文件，而 file 标识声明本身的源位置。parentId 基于包含它的测试套件的源文件和层级名称路径。

🌐 Every benchmark-scoped event contains runId, fileRunId, entryFile, benchId, parentId, and namePath. runId and fileRunId are opaque and change between runs. entryFile identifies the top-level benchmark file whose loading caused the declaration, while file identifies the source location of the declaration itself. parentId is based on the containing suite's source file and hierarchical name path.

在异步套件声明完成后，进程内运行器会按照声明顺序为收集到的每个基准测试发出一个 'bench:plan' 事件。该运行器的所有计划会在其套件钩子或基准测试回调执行之前发出。使用进程隔离时，文件会在不同的子进程中运行，所以后面的文件的计划会在前一个子进程完成之后才发出。没有隔离时，所有文件共享一个运行器，它们的计划会在任何基准测试执行之前发出。计划数据包含基准测试范围的身份、位置、标签以及 基准测试结果 中描述的参数，同时还包括：

🌐 After asynchronous suite declarations settle, an in-process runner emits one 'bench:plan' event for every benchmark it collected, in declaration order. All plans from that runner are emitted before its suite hooks or benchmark callbacks run. With process isolation, files run in separate children, so plans for a later file are emitted after an earlier child has completed. With no isolation, all files share one runner and their plans are emitted before any benchmark executes. Plan data contains the benchmark-scoped identity, location, tags, and parameters described in benchmark result, together with:

• diagnosticChannels <string[]> 在每次回调期间订阅的继承字符串通道名称。
• samples <number> 在运行级别覆盖之后，测量回调调用的有效最大次数。
• warmup <number> 运行级别覆盖后未报告的热身回调调用的有效次数。
• timeout <number> | <null> 超时时间（毫秒），如果没有配置超时则为 null。
• yieldBetweenSamples <boolean> 事件循环轮次是否安排在采样回调之间。
• selected <boolean> 在应用 skip、only 和 namePattern 选择后，该基准是否有资格运行。执行仍可能因重复声明、套件构建、钩子、终止或其他运行时失败而被阻止。
• skip <boolean> | <string> 当 selected 是 false 时，明确的跳过值或选择原因，例如 'only' 或 'name pattern'。

该计划包含执行者已知的执行设置。运行时版本、操作系统、处理器和其他环境元数据故意留给报告工具和更高级的工具收集。

🌐 The plan contains execution settings known to the runner. Runtime version, operating system, processor, and other environment metadata are intentionally left for reporters and higher-level tools to collect.

'bench:complete' 数据包含一个 基准测试结果。失败的结果有一个额外的 error 属性，并且可能包含错误发生前记录的样本。跳过的结果有一个额外的 skip 属性，以及一个空的 samples 数组。'bench:diagnostic' 报告加载、套件和钩子错误，以及公共上下文诊断。上下文诊断包含基准范围内的身份字段、phase、index、message、level、源位置，以及可选的 detail。'bench:summary' 包含整体的 runId、fileRunId、entryFile、success、counts、duration_ns 和 file 属性。fileRunId、entryFile 和 file 是 <string> | <null>；当汇总多个文件时，它们是 null。