Promise.all 无法控制 RabbitMQ 并行消费数量，因其仅等待已有 Promise，而 RabbitMQ 是流式逐条触发回调；需用 p-limit 在 consume 回调内限流，配合 prefetch 实现可靠并发控制。
不能直接用 Promise.all 控制 RabbitMQ 消息的并行消费数量——它只负责等待 Promise，不控制创建时机；消息一旦被 channel.consume 接收并调用 ack 前的处理函数，就会立刻执行，Promise.all 完全插不上手。
为什么 Promise.all 在 RabbitMQ 消费中失效
Promise.all 的作用是「等待一组已存在的 Promise 结束」，而 RabbitMQ 消费是持续接收、逐条触发回调的过程。你无法提前拿到所有待处理的 Promise，更没法把它们一次性塞进 Promise.all 数组里。
常见错误现象：
- 写了个
Promise.all(messages.map(handle))，但messages根本不存在——RabbitMQ 是流式推送，不是批量拉取 - 在
channel.consume回调里直接await handle(msg)，结果所有消息串行处理，吞吐暴跌 - 加了
Promise.all包裹但没限流，Node.js 进程瞬间 spawn 出几十个并发请求或 DB 查询，OOM 或连接池打满
p-limit 是最轻量可靠的并发控制器
真正起作用的是在消费回调内部，用 p-limit 包装业务处理逻辑，让「最多 N 个 handle 同时执行」，其余自动排队。
安装与基础用法：
wechat-article-extraction-mp-weixin-qq-com news-webpage-cleaning blog-post-parsing metadata-extraction-title-author-date multiple-output-formats-markdown-json-plain-text batch-processing-support
下载
基于三引擎设计，从微信文章、新闻和博客网页提取干净内容，支持标题作者日期元数据，多格式和批量处理。
npm install p-limit
示例（最大同时处理 3 条消息）：
const pLimit = require('p-limit');
const limit = pLimit(3);
channel.consume(queueName, async (msg) => {
if (msg !== null) {
// 关键：用 limit 包裹实际业务逻辑，不是包裹 consume 回调本身
await limit(async () => {
try {
await processMessage(msg.content.toString());
channel.ack(msg);
} catch (err) {
channel.nack(msg, false, true); // 重入队
}
});
}
});
注意点：
-
limit返回的是一个函数，必须调用它（带括号），才能把任务塞进队列 - 不要在
limit外层再套await消费回调——这会阻塞 AMQP 流水线，导致 prefetch 生效异常 -
limit不影响channel.prefetch，两者要配合：比如prefetch = 10+limit(3)，表示最多缓存 10 条未确认消息，但只并发处理其中 3 条
自己实现简易并发控制器要注意的坑
如果不想引入 p-limit，可手写一个基于队列的控制器，但必须避开几个典型陷阱：
- 别用
executing.length >= limit做同步判断——JS 单线程下这个值永远不准，要用Promise.race(executing)等待最快完成的任务 - 别在
then里直接shift()下一条——RabbitMQ 消息对象msg是一次性的，msg.ack()后再访问会报错 - 必须确保每个任务都调用
ack或nack，否则 unacked 消息越积越多，RabbitMQ 内存爆涨 - 错误处理要完整：Promise reject、process 异常、网络超时，都要落到
nack或reject分支，避免消息静默丢失
真正关键的不是“怎么等”，而是“怎么不让太多任务同时启动”；p-limit 把队列调度、状态跟踪、错误传播都封好了，比自己拼 Promise.all + 计数器 + 手动 shift 可靠得多——尤其在长时间运行的服务里，少一个竞态，就少一个凌晨三点的告警。
