AMQP-CPP是当前最省心的C++客户端选型，它将AMQP-0-9-1协议状态机与libev事件循环深度绑定，自动处理心跳、重连、QoS等关键逻辑，避免rabbitmq-c裸调导致的静默崩溃。
直接用 rabbitmq-c 写生产级 C++ 客户端，90% 的人会在连接断开、心跳超时、未确认消息堆积这三处静默崩溃。真正能扛住线上流量的方案，必须绕过裸调 C API 的陷阱，用封装层把重连、QoS、序列化、线程模型全收口。
AMQP-CPP 是当前最省心的 C++ 客户端选型
它不是“又一个封装”，而是把 AMQP-0-9-1 协议状态机和 libev 事件循环绑死的设计。你不用手动 select() 或 poll() socket，也不用自己写心跳包定时器——这些都在 AMQP::Connection 和 AMQP::Channel 里闭环了。
- 连接失败时，
AMQP::Connection默认不自动重连，必须显式调用reconnect()；但你可以监听onError()回调，在里面触发重连逻辑 - 所有回调（如
onMessage()）都在同一个 event loop 线程执行，避免多线程锁竞争；若需分发到业务线程，得自己加队列中转 - 不支持 OpenSSL 1.1.1+ 的默认宏定义，编译报错
"OPENSSL_API_COMPAT expresses an impossible API compatibility level"时，要在 CMakeLists.txt 里加add_definitions(-DOPENSSL_API_COMPAT=0x10100000L)
发布消息必须配齐三个持久化要素
只设 deliveryMode = 2 不够，RabbitMQ 要求交换机、队列、消息三者同时声明为持久化，消息才真能落盘。否则 broker 重启后，消息就丢了。
- 交换机声明：用
channel.declareExchange("my_exchange", "topic", AMQP::durable) - 队列声明：用
channel.declareQueue("my_queue", AMQP::durable) - 发布时：构造
AMQP::Envelope后调用envelope.setDeliveryMode(2)，再传给channel.publish() - 漏掉任意一项，
deliveryMode = 2都无效；且队列名必须和绑定时一致，否则路由失败无日志
消费端必须手动 ACK + 合理设置 prefetch
默认情况下 AMQP-CPP 消费是 auto-ack 模式，消息一推过来就立刻确认，服务崩溃时正在处理的消息就永远丢失。要可靠，就得关掉 auto-ack，自己控制确认时机。
立即学习“C++免费学习笔记（深入）”；
- 创建 channel 时传入
AMQP::noack = false参数 - 在
onMessage()回调里，处理完业务逻辑后，显式调用channel.ack(deliveryTag) - 务必设置
channel.qos(1)（或更小值），否则 RabbitMQ 会批量推送多条消息，而你的单线程 event loop 无法并行处理，导致堆积和超时 - 如果业务处理可能耗时较长，别在回调里直接做重操作；应把
deliveryTag和消息内容转发到 worker 线程，处理完再回主线程调ack()
断连重连不能只靠 try/catch
rabbitmq-c 层面的 socket 断开不会抛 C++ 异常，AMQP-CPP 的 onError() 也只报协议错误（比如帧解析失败）。真正的网络中断，得靠 onDetached() 回调感知。
- 注册
onDetached()回调，在里面停掉所有 channel，清空待发消息缓存，然后延迟几秒再调reconnect() - 重连后不要立刻发消息，先等
onReady()触发，再重新 declare exchange/queue/bind，最后恢复 publish/consume - 避免在
onDetached()里直接 new 对象或调用阻塞函数，它运行在 libev 的 I/O 线程，卡住会导致整个 event loop 停摆
最易被忽略的是：AMQP-CPP 的 Channel 不是线程安全的，哪怕你只在一个线程里用，只要涉及多个 Channel 实例（比如一个发、一个收），它们共享底层 connection 的 socket，就必须确保所有对同一 Connection 的操作都发生在同一个 event loop 线程。跨线程调用 publish() 或 ack() 会引发内存损坏，且问题往往延后数分钟才暴露。
