C++如何调用RabbitMQ发送消息？（AMQP C++客户端示例）

生产环境优先选librabbitmq-c，因其稳定、文档全、错误码明确；cppamqp长期不维护、不支持tls 1.3、编译易受boost版本限制，且ssl/tls下易崩溃或回调失效。

用 librabbitmq-c 还是 cppamqp？别选错底层库

直接结论：生产环境优先选 librabbitmq-c（C 风格 API），不是因为它多优雅，而是它稳定、文档全、错误码明确；cppamqp 虽然接口更 c++ 化，但长期不维护、不支持 TLS 1.3、编译时容易卡在 Boost 版本上。

常见错误现象：cppamqp 示例跑通了，一加 SSL/TLS 就崩溃，或者连接超时后不触发回调；而 librabbitmq-c 即使连不上，amqp_login 也会返回明确的 AMQP_STATUS_CONNECTION_CLOSE 或 AMQP_STATUS_TIMEOUT。

• librabbitmq-c 是 RabbitMQ 官方推荐的 C 客户端，C++ 项目里用 extern “C” 包一层就能用，无依赖污染
• 如果项目已重度使用 Boost，且只跑在内网、不碰 TLS，cppamqp 可临时用，但别指望它处理 channel Error 的自动恢复
• 别碰 SimpleAmqpClient —— 它基于 librabbitmq-c 封装，但把关键错误码吞掉了，debug 时只剩 std::runtime_error 一个模糊异常

amqp_basic_publish 发不出消息？检查这三处硬编码陷阱

90% 的“发消息没反应”问题，不是网络不通，而是参数传错了，而且错得非常隐蔽。

• exchange 名字为空字符串 "" 是合法的（对应默认 exchange），但如果你填了 "amq.direct" 却没事先声明，RabbitMQ 会静默丢弃，不报错也不回执
• routing_key 如果带斜杠（比如 "user/123"），而队列绑定时用的是 "user.*" 这类通配符，注意 amqp_basic_publish 不做模式匹配，只按字面量路由
• amqp_bytes_t body 必须是堆上分配的内存（malloc 或 new），不能传栈变量地址，否则 publish 后立刻释放，broker 收到的是野指针内容

示例片段（安全写法）：

立即学习“C++免费学习笔记（深入）”；

amqp_bytes_t body = amqp_cstring_bytes("hello"); amqp_basic_publish(conn, 1, amqp_cstring_bytes(""),                     amqp_cstring_bytes("my_queue"), 0, 0, NULL, body); // 注意：body 内存由 amqp_cstring_bytes 内部 malloc，publish 后需 amqp_bytes_free(body)

连接断开后怎么重连？别在 amqp_simple_wait_frame 里硬等

直接调 amqp_simple_wait_frame 等响应，一旦网络抖动或 broker 重启，它就卡死在 select() 上，既不超时也不通知你连接没了。

• 必须用 amqp_get_rpc_reply 检查每一步操作的返回值，比如 amqp_login 返回非 AMQP_STATUS_OK 就该立即 close + 重建 connection
• 设置 socket 超时：在 amqp_socket_open 前，调 amqp_set_sockfd 后手动设 setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, ...)，否则默认阻塞无限期
• 不要复用 amqp_connection_state_t 变量：重连时必须 amqp_destroy_connection 旧句柄，再 amqp_new_connection，否则 channel id 会冲突，后续 basic.publish 返回 AMQP_STATUS_WRONG_STATE

为什么发了 100 条只收到 3 条？确认机制没开对

RabbitMQ 默认关闭 publisher confirms，amqp_basic_publish 成功只代表消息进了 client 缓冲区，不代表 broker 已接收。要真正确认送达，必须显式开启并轮询确认帧。

• 调用 amqp_confirm_select 后，每次 amqp_basic_publish 才会触发 confirm 流程；不调这个，所有 publish 都是“发完即忘”
• confirm 模式下必须循环调 amqp_simple_wait_frame 等 AMQP_BASIC_ACK_METHOD 或 AMQP_BASIC_NACK_METHOD，不能只发不收
• 性能影响：开启 confirm 后吞吐下降 30%~50%，如果业务允许少量丢失，不如关掉 confirm，改用 mandatory + return listener 做兜底

容易被忽略的地方：confirm 模式下，broker 返回的 delivery_tag 是单调递增的整数，但它**不是**你发消息的序号——如果你中间有未确认消息，tag 会跳变，不能拿它当数组下标去查本地缓存。