countqueuingstrategy 是 streams api 中基于元素计数的轻量级排队策略，以 highwatermark 为阈值控制队列长度，每 chunk 计 1，超限则暂停写入并返回 pending promise，适用于消息、日志等按条处理场景。
CountQueuingStrategy 是 Web API 中 Streams API 提供的一种内置排队策略，专用于控制可读流（ReadableStream）或可写流（WritableStream）的内部队列长度。它不依赖外部状态或复杂调度逻辑，仅通过统计待处理的“元素个数”来触发背压——当队列中元素数量达到指定的 highWaterMark 时，流会自动暂停生产或拒绝写入，从而实现轻量、声明式、零侵入的排队控制。
核心机制：用计数代替复杂度
CountQueuingStrategy 的本质是把“排队控制”简化为一个整数比较：
- 每个写入的 chunk（无论大小）都计为 1 个元素，不考虑字节长度或处理耗时
- 内部维护一个运行计数器，随
controller.enqueue()增加，随controller.close()或消费完成减少 - 当计数值 ≥
highWaterMark，流自动进入 waiting 状态，writable.ready变为 false，write()返回 pending promise - 一旦消费者调用
read()或内部消化完成，计数下降，流自动恢复
典型使用场景与代码示例
适用于对吞吐敏感但无需精确字节限流的场景，例如：
- 消息批量转发（每条 JSON 消息视为 1 个元素）
- 日志行缓冲（每行日志作为独立 chunk）
- 前端任务队列节流（每个任务对象入队计 1）
示例：构建一个最多缓存 5 条消息的可写流
const strategy = new CountQueuingStrategy({ highWaterMark: 5 });
const writable = new WritableStream({
write(chunk) {
console.log('处理消息:', chunk);
}
}, strategy);
// 连续写入 7 条消息
for (let i = 0; i
对比其他策略的关键优势
相比 ByteLengthQueuingStrategy 或自定义策略，CountQueuingStrategy 的轻量性体现在：
- 无序列化开销：不需计算 chunk 字节长度，适合非 ArrayBuffer 类型（如 string、object）
- 无状态同步成本：不依赖外部计数器或锁，完全由流引擎内建管理
- 语义清晰：highWaterMark 直观对应“最多积压几条”，便于业务对齐（如“最多积压 10 个用户请求”）
- 低内存占用：仅维护一个整数，无额外 buffer 或 map 结构
注意事项与边界情况
使用时需注意其设计边界：
- chunk 必须是“可计数单位”——若传入大数组但按整体计为 1，可能造成单次处理压力过大
- 不感知处理耗时：即使某 chunk 处理慢，只要数量未超限，仍会继续接收，需配合异步消费逻辑兜底
- 不可动态修改
highWaterMark，需在构造时确定；如需弹性，应封装为策略工厂 - 与
pipeTo()配合时，目标流的策略独立生效，需分别配置
