async_accept是一次性操作，必须在handler中无错时立即重新调用才能持续接收连接；否则服务器仅处理一个连接即停止。
async_accept 之后必须重新调用才能接收下一个连接
很多人写完 acceptor.async_accept(socket, handler)，在 handler 里处理完就结束，结果服务器只接受一个连接就“卡住”了。这是因为 async_accept 是一次性操作——它不是监听循环，而是发起一次异步等待，完成后不会自动续订。
正确做法是在 handler 内部（且仅当没有错误时）立刻再调用 async_accept：
void handle_accept(tcp::socket socket, const boost::system::error_code& ec) {
if (!ec) {
// 启动这个 socket 的异步读写（见下节）
start_session(std::move(socket));
// ✅ 关键：立即发起下一次 accept
acceptor.async_accept(
make_socket(),
[this](boost::system::error_code ec, tcp::socket socket) {
handle_accept(std::move(socket), ec);
}
);
}
}
- 不要在 handler 外部用 while 循环调用
async_accept—— 这会阻塞 io_context，破坏异步模型 - 如果 handler 中发生错误（如
ec == boost::asio::error::operation_aborted），不应重试；这是正常 shutdown 行为 - 注意
make_socket()应返回新构造的tcp::socket，避免复用已关闭或移动过的 socket 实例
session 对象必须保证生命周期长于所有 pending 异步操作
异步读写（async_read / async_write）是延迟执行的，handler 可能在任意时刻被回调。如果 session 对象（比如一个 lambda 捕获的局部变量、或栈上分配的对象）提前析构，回调就会访问野指针，导致崩溃或未定义行为。
常见错误写法：auto session = std::make_shared<session>(std::move(socket)); session->start();</session> —— 看似用了 shared_ptr，但如果 start() 内部没把自身 shared_ptr 传给 handler，那它仍可能被释放。
- 推荐模式：让 session 继承
std::enable_shared_from_this<session></session>，并在每个异步调用中用self_ = shared_from_this()捕获强引用 - 例如
async_read(..., [self = shared_from_this()](const auto& ec, size_t n) { ... }); - 不要用裸指针或 this 指针直接捕获到 lambda 中
- 如果 session 启动了多个嵌套异步操作（如读完再写、写完再读），每次都要确保传递有效 lifetime 控制
io_context::run() 必须在至少一个线程中持续运行，且不能提前退出
io_context::run() 不是“启动一次就完事”的函数，它是事件循环的入口。一旦返回，所有 pending 异步操作将不再被调度，新连接无法进入，已有连接的回调也不会触发。
典型误用：io_context.run(); 放在 main 末尾但没加同步机制，或被 try-catch 吞掉异常后静默退出。
- 生产环境应至少有一个线程调用
io_context.run()，多线程可配合io_context::work防止空转退出 - 若需优雅关闭，先调用
io_context.stop()，再等待所有线程从run()返回 - 注意
run()在无 pending 操作且无 active work 时会立即返回 —— 所以 acceptor 启动前务必先构造好 work 对象（如auto work = make_work_guard(io_ctx);） - Windows 下若使用
IOCPbackend，还需确保线程数 ≥ CPU 核心数才能充分并发；Linux 下epoll对单线程支持较好，但高吞吐仍建议多线程 +run()分发
buffer 生命周期必须覆盖 async_write 的整个异步过程
async_write 接收的 buffer（如 boost::asio::buffer(data, len)）只是视图，不拷贝数据。如果 data 是局部数组、临时 string 或已 move 的 vector，handler 还没执行时内存可能已被回收。
最常踩的坑：用 std::string msg = "hello"; async_write(socket, buffer(msg)); —— msg 在 handler 调用前就析构了。
- 安全做法：把待发送数据作为 session 成员变量持有（如
std::vector<char> write_buffer_</char>），再用buffer(write_buffer_) - 或者用
boost::asio::dynamic_buffer管理可增长缓冲区 - 避免对
std::string::c_str()直接取地址传入 buffer —— c_str() 返回的指针在 string 修改或析构后失效 - 注意
async_write是“全写完才回调”，但 buffer 内存必须全程有效；而async_write_some则更底层，需自行处理分片和重试逻辑
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
