必须堆分配OVERLAPPED并由连接对象持有，禁止栈存储或跨线程复用；CompletionKey宜设为Connection*指针；CreateIoCompletionPort并发数建议设0，线程池固定2–4个。
直接封装成类是可行的，但必须绕开 OVERLAPPED 生命周期管理这个最常崩的点——它不能是栈变量、不能被拷贝、不能跨线程复用，否则 GetQueuedCompletionStatus 返回后 lpOverlapped 指针就野了。
为什么不能把 OVERLAPPED 放在栈上
IOCP 的异步调用（如 WSARecv、WSASend）只接受一个 OVERLAPPED* 指针，内核会把它当作不透明句柄长期持有，直到 I/O 完成并入队。如果这个结构体在函数返回后就析构（比如放在栈上或局部 new 后没配对 delete），那完成包里的 lpOverlapped 就指向垃圾内存，后续 reinterpret_cast 解包时必然 crash 或读到错乱数据。
实操建议：
- 每个 socket 连接对象（如
Connection类）必须持有一个堆分配的OVERLAPPED子类，例如struct IoContext : OVERLAPPED { int op_type; void* user_data; }; - 所有
WSARecv/WSASend调用都传该对象地址，且绝不 delete —— 等GetQueuedCompletionStatus返回后再统一回收 - 别用
std::unique_ptr<overlapped></overlapped>直接管理，因为OVERLAPPED是 POD，没有虚析构；推荐用std::unique_ptr<iocontext void></iocontext>配自定义 deleter
CreateIoCompletionPort 的 NumberOfConcurrentThreads 怎么设
这个参数不是“我要开几个线程”，而是“最多允许几个线程同时从完成端口取包”。设为 0 表示不限制，但实际并发数仍受工作线程数量限制；设为 1 就退化成单线程串行处理，失去 IOCP 优势。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
常见错误是照抄文档写 SYSTEM_INFO.dwNumberOfProcessors，结果在 64 核机器上拉 64 个线程，反而因锁竞争和缓存抖动拖慢吞吐。真实压测表明，多数网络服务设为 min(4, num_cores) 更稳。
实操建议：
- 初始化完成端口时传
0，由工作线程池数量控制实际并发度，更可控 - 线程池大小建议固定为 2–4 个，避免频繁创建销毁；每个线程循环调用
GetQueuedCompletionStatus，不要用WaitForSingleObject等别的信号 - 若业务有 CPU 密集型处理（如协议解包、加解密），应把耗时逻辑移出完成端口线程，用生产者-消费者队列转给专用计算线程
怎么让 CompletionKey 不只是 socket 句柄
CreateIoCompletionPort 绑定 socket 时传的 CompletionKey 参数，在 GetQueuedCompletionStatus 返回时原样回传。很多人只传 (DWORD_PTR)socket，结果后续要查连接状态就得遍历 map，O(n) 查找拖慢高并发场景。
实操建议：
- 把
CompletionKey设为指向连接对象（如Connection*）的指针，前提是该对象生命周期长于 socket 且不会被移动（禁用std::vector存储，改用std::unordered_map<socket std::unique_ptr>></socket>或内存池） - 若担心指针失效，可传一个稳定 ID（如原子递增的
int64_t），再配合无锁 hash 表索引，但增加一层间接访问成本 - 绝对不要在
CompletionKey里塞临时对象地址或栈变量地址，哪怕只存活几毫秒也不行
最难缠的不是 API 调用顺序，而是所有异步操作的生命周期必须严格对齐：socket 创建 → OVERLAPPED 分配 → 关联完成端口 → 发起异步 → 完成通知 → 处理数据 → 清理上下文。漏掉任一环，轻则内存泄漏，重则访问违规。尤其注意关闭 socket 时，必须等所有挂起的 OVERLAPPED 都完成或被取消（用 CancelIoEx），再释放内存。
