NestJS 中 @golevelup/nestjs-rabbitmq 的 RPC 调用需依赖 AmqpConnection.request() 自动生成 correlationId 和 replyTo，手动 publish 时必须显式设置二者，否则响应无法匹配；服务端须原样透传 correlationId，且临时队列与 correlationId 绑定生命周期。
NestJS 用 @golevelup/nestjs-rabbitmq 做 RPC 时，correlationId 不需要手动设置——它由模块在发送请求前自动生成并注入到消息属性中，前提是使用了正确的 RPC 发送方式。
为什么直接发消息不带 correlationId？
如果你绕过 AmqpConnection.request()，改用 publish() 或原始 channel.sendToQueue() 手动发消息，correlationId 就不会自动存在。RabbitMQ 自身不生成这个值，它完全依赖客户端逻辑。
-
request()内部会：生成 UUID 字符串、设置properties.correlationId、监听临时 reply-to 队列、绑定超时清理 - 手写
publish()调用时，必须显式构造options.properties并赋值correlationId和replyTo，否则服务端返回的消息无法被客户端匹配 - 常见错误现象：
request()永远不 resolve，或收到响应但Promise已超时，基本都是因为 reply-to 队列名不一致或correlationId缺失/错位
AmqpConnection.request() 的实际行为
这个方法不是“发完就不管”，而是启动了一个带生命周期管理的等待流程。它背后维护了一个 Map<string deferred></string>，key 就是生成的 correlationId。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 每次调用
request()，都会生成新的correlationId（默认用uuid.v4()），你无法覆盖或复用 - 它自动创建一个独占、自动删除的临时队列，并把队列名塞进
properties.replyTo - 响应消息必须同时满足两个条件才会触发 resolve：队列名匹配 +
correlationId字符串完全相等 - 如果服务端返回时漏设
correlationId，或者用了错误的大小写（比如全小写 vs 首字母大写），匹配就失败
服务端必须原样透传 correlationId
用 @RabbitRPC 装饰器定义的处理器，框架会自动从入站消息提取 correlationId 和 replyTo，并在响应时还原。但如果你手动处理消息（比如用 @RabbitSubscribe + ack），就必须自己读取和设置：
await channel.sendToQueue(
msg.properties.replyTo,
Buffer.from(JSON.stringify(result)),
{
correlationId: msg.properties.correlationId, // 必须复制！不能硬编码、不能忽略
contentType: 'application/json',
}
);
- 遗漏
correlationId是最常踩的坑，尤其在做错误响应时：成功路径写了，catch块里直接sendToQueue却没带这个字段 - 不要用
msg.fields.routingKey或其他字段代替correlationId做匹配，客户端只认properties.correlationId - 跨语言调用（比如 NestJS 客户端 + Python 服务端）时，注意对方是否把
correlationId当字符串处理——某些客户端库会把它转成数字再发，导致类型不一致
真正容易被忽略的点是：临时 reply-to 队列的生命周期和 correlationId 的作用域是一对一绑定的，删掉队列或清空 Map 里的 key，就再也收不到那个响应。别在日志里只打 correlationId 却不记录对应 reply-to 队列名，排查超时时这两者缺一不可。
