不用手写actor调度器，因易导致消息乱序、竞争、调度失效及语义混淆；caf基于asio封装了邮箱、单线程执行、崩溃隔离等正确actor语义，并提供无锁队列、自动生命周期管理与背压控制。
为什么不用手写 Actor 调度器
直接基于 asio::io_context 手写 Actor 调度器看似灵活，实则极易踩坑：消息乱序、共享状态竞争、线程局部调度失效、post() 与 dispatch() 语义混淆导致隐式同步开销。asio 本身不提供 Actor 语义（如邮箱、单线程独占执行、崩溃隔离），强行模拟会重复造轮子且性能不如成熟方案。
推荐用 cpp-actors（CAF）而非裸 asio
CAF（C++ Actor Framework）底层基于 asio，但封装了正确的 Actor 行为：每个 actor 默认绑定到一个轻量级 event-based actor，使用 caf::io::middleman 复用 asio 的 io_context，支持本地/远程透明通信，且默认启用 lock-free mailbox（基于 boost::lockfree::queue）。关键优势：
-
spawn()创建的 actor 自动获得专属 mailbox 和执行上下文，无需手动strand - 消息发送用
self->send(dest, msg)，底层自动序列化+线程安全入队 - 避免
std::shared_ptr<this></this>捕获导致的循环引用——CAF 提供anon_send()和生命周期感知的become() - 启用
-DCAF_ENABLE_OPENCL=OFF -DCAF_ENABLE_QT=OFF编译可减小二进制体积，不影响核心性能
高频消息场景下的关键配置
默认 CAF mailbox 是无界队列，高吞吐下可能 OOM。需显式限制并处理背压：
auto cfg = caf::actor_system_config{};
cfg.set("caf.scheduler.max-threads", 8);
cfg.set("caf.middleman.network-backend", "asio");
// 关键：限制每个 actor 邮箱长度，超限时触发 backpressure
cfg.set("caf.scheduler.max-mailbox-size", 1024);
// 启用批处理减少 asio 唤醒次数
cfg.set("caf.io.batch-sends", true);
caf::actor_system sys{cfg};若消息处理函数中调用阻塞 IO（如文件读写），必须用 sys.spawn_io_actor<:io::blocking_actor>(...)</:io::blocking_actor>，否则阻塞会拖垮整个 io_context 线程池。
立即学习“C++免费学习笔记（深入）”；
与裸 asio 混用时的陷阱
当需要在 actor 内部调用 asio 原生 API（如 async_read）时，必须确保回调在 actor 所属的 execution_context 上执行：
self->send(self, std::make_tuple(std::move(buf), std::move(handler)));
// ❌ 错误：直接 bind asio 回调，可能跨线程执行
// socket_.async_read_some(..., [this](auto...) { handle(); });
// ✅ 正确：通过 self->enqueue() 把控制权交还 actor 调度器
socket_.async_read_some(
boost::asio::buffer(buf),
[self](const boost::system::error_code& ec, size_t n) {
self->enqueue(self, caf::make_message_id(), caf::make_message(ec, n));
}
);Actor 模型的性能瓶颈从来不在消息传递本身，而在于 mailbox 处理逻辑是否真正无锁、是否意外引入同步等待、以及是否让非 actor 代码绕过调度器直连 asio。CAF 的价值不是“更简单”，而是把这几处复杂性封在正确抽象之下。
