直接为每个accept连接创建std::thread会导致线程数失控，引发栈内存耗尽、调度开销剧增、文件描述符占满（emfile错误）等问题，必须用线程池限流并配合非阻塞socket与合理fd生命周期管理。
用 std::thread 启动多个 accept 循环会出什么问题
直接为每个连接 accept() 后开一个 std::thread，短期能跑，但很快会崩溃或卡死。根本原因是：没有限制线程数量，连接洪峰一来，瞬间创建几百个线程，栈内存耗尽、调度开销爆炸、文件描述符被占满——accept() 返回 -1 且 errno == EMFILE 就是典型信号。
实操建议：
- 必须设硬性线程上限（比如 8–32，取决于 CPU 核数和 I/O 密度），用线程池管理，而非每连接一新线程
-
accept()调用前检查返回值，失败时立即if (fd == -1) { if (errno == EAGAIN || errno == EWOULDBLOCK) continue; else break; } - 监听 socket 必须设为非阻塞（
fcntl(fd, F_SETFL, O_NONBLOCK)），否则单个accept()卡住就拖垮整个循环
为什么别手写 HTTP 解析而要用 readline + 状态机
HTTP 请求头以 "\r\n\r\n" 结尾，但真实网络中数据是流式到达的：一次 recv() 可能只读到半个 Host:，下一次才到换行。手写 strstr(buffer, "\r\n\r\n") 忽略了缓冲区边界和多次收包场景，极易解析错位或死循环。
实操建议：
- 维护一个 per-connection 的
std::string缓冲区，每次recv()追加到末尾 - 用
size_t pos = buf.find("\r\n\r\n");查找完整头部，找不到就继续收；找到后截取buf.substr(0, pos + 4)解析，再把剩余部分（可能是 body）留在缓冲区 - GET 请求可忽略
Content-Length，但 POST 必须按该字段收完全部 body，否则后续请求粘包
epoll 和 std::thread 混用时 fd 生命周期怎么管
常见错误：在线程里 close(fd) 后，主线程的 epoll_wait() 还在监视这个 fd，下次触发就报 EBADF 错误；或者多个线程同时 recv() 同一个 fd，数据乱序或 EAGAIN 判定失效。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
实操建议：
- 所有 fd 的创建、关闭必须由 epoll 所在线程（通常是主线程）统一管理；工作线程只做计算和构造响应，不碰 fd
- 用
epoll_ctl(epfd, EPOLL_CTL_DEL, fd, nullptr)在 close 前先从 epoll 移除 - 如果用线程池处理请求，把 fd 和已读缓冲区打包成结构体，通过无锁队列传给 worker，worker 处理完把响应字节流发回主线程，由主线程
send()
响应写入时遇到 send() 返回 SOCKET_ERROR 怎么办
send() 不保证一次发完全部数据，尤其在高吞吐或慢客户端下常返回小于 len 的正值（已发字节数），也常因缓冲区满返回 -1 且 errno == EAGAIN。直接忽略返回值会导致响应截断，浏览器卡在 loading。
实操建议：
- 对每个 fd 维护一个待发送队列（如
std::deque<:string></:string>），每次send()尝试发队首，成功则 pop，失败且errno == EAGAIN就注册EPOLLOUT事件等待可写 - 收到
EPOLLOUT后重试发送，直到队列为空，再注销EPOLLOUT（否则持续触发） - 务必检查
send()返回值是否为-1且errno是ECONNRESET或ENOTCONN，此时应立即关闭 fd 并清理对应状态
多线程 HTTP 服务器最易被忽略的是连接关闭的竞态：一方调用 close() 时，另一方可能正处在 recv() 或 send() 中间。必须为每个连接设计明确的状态机（如 READING_HEADER → READING_BODY → WRITING_RESPONSE → CLOSING），所有 I/O 操作前检查当前状态，避免非法调用。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
