amqplib 不支持 ch.ackAll()，唯一批量操作是 channel.nack(..., multiple: true)，但仅用于拒绝；安全批量确认需手动缓存消息并逐条调用 channel.ack()，同时注意内存泄漏与幂等性。
ch.ackAll 不是 amqplib 提供的合法方法
直接调用 ch.ackAll() 会抛出 TypeError: ch.ackAll is not a function。amqplib 的 Channel 实例（无论 Promise 还是 Callback API）**根本不提供 ackAll 方法**。这是开发者常因误解 RabbitMQ 文档或混淆其他客户端（如 Python 的 pika）而踩的第一个坑。
想批量确认，只能用 channel.nack(..., multiple: true) 反向实现
amqplib 支持的唯一“批量”操作是 channel.nack() 的 multiple 参数，但它只适用于“拒绝”，不能用于“确认”。也就是说：你无法通过一次调用确认一批消息；但你可以用 channel.nack(msg, true, false) 拒绝当前 deliveryTag 之前所有未确认的消息（即清空待确认队列）。
这种“反向批量”带来的业务风险包括：
- 误清空：若某条中间消息已处理成功但未 ack，
nack(..., multiple: true)会把它和后续未处理的消息一起丢弃或重入，造成重复处理或丢失 - 语义错位：nack 是失败路径，用它来模拟“批量成功”违背设计意图，调试和监控时指标失真（例如 nack_count 暴涨但实际无错误）
- 无法区分状态：你失去了对每条消息独立确认的能力，无法做细粒度的幂等判断、死信归档或处理耗时统计
真正安全的批量确认必须手动循环 + 逐条 ack
如果你确实需要在某种聚合逻辑后统一确认（例如批处理 10 条日志后落库再确认），唯一合规做法是缓存消息引用，处理完成后遍历调用 channel.ack()：
const pendingMessages = [];
channel.consume(queue, (msg) => {
pendingMessages.push(msg);
if (pendingMessages.length >= 10) {
processBatch(pendingMessages).then(() => {
pendingMessages.forEach(m => channel.ack(m)); // 必须逐条
pendingMessages.length = 0;
});
}
}, { noAck: false });
注意这里的关键约束：
- 必须确保
processBatch是原子的或具备重试/幂等性，否则部分ack()执行失败会导致消息卡住 - 不能在
ack()前销毁msg引用（比如 JSON.parse 后丢弃原始 msg），因为ack()内部依赖msg.fields.deliveryTag - 如果处理中抛错且未 catch，整个 pendingMessages 数组会滞留，需加超时或计数兜底
更隐蔽的风险：prefetch 设置与内存泄漏耦合
当试图“攒批”时，常会配合增大 channel.prefetch(100) 来拉更多消息进内存。但 amqplib 不会自动清理已 ack() 的消息引用——如果你把 msg 存在长生命周期数组里又忘了清空，V8 垃圾回收器无法释放这些 Buffer 和对象，导致内存缓慢上涨。尤其在高吞吐场景下，几小时就可能 OOM。
所以，哪怕只是临时缓存，也要严格配对：push → process → ack → splice/shrink。别依赖“反正消息小”这种直觉。
