生产环境优先选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 会跳变，不能拿它当数组下标去查本地缓存。
