最简双端通信需用std::thread分离收发：服务端accept后启接收线程，客户端用两线程分别处理输入发送与recv接收；消息以\n结尾防粘包，send/recv须循环处理返回值，Windows需WSAStartup/WSACleanup，Linux需-lpthread链接。
用 std::thread + socket 实现最简双端通信，别碰 Boost.Asio 初学陷阱
想跑通一个能收发消息的命令行聊天室，核心就两件事：建立 TCP 连接、并发处理收/发。C++ 标准库本身不带网络 API，得调系统 socket（Linux/macOS 用 sys/socket.h，Windows 用 winsock2.h），但线程可以用标准 std::thread。初学者最容易卡在阻塞模型和线程同步上——比如发消息时 recv() 卡住，或者两个线程同时写 std::cout 导致输出错乱。
实操建议：
- 先写单向通信（如只让客户端发、服务端收），验证 socket 连通性，再加双向
- 收发逻辑必须分离到不同线程，否则一端不输入就会卡死另一端
- 所有
std::cout输出前加std::lock_guard<:mutex></:mutex>，避免终端文字粘连 - Windows 下记得在 main 开头调用
WSAStartup，结尾调用WSACleanup，漏掉会直接socket()失败
send() 和 recv() 必须检查返回值，否则收不到消息大概率是这俩没处理
这两个函数不是“发完/收完才返回”，而是“尽力操作后返回实际字节数”。常见错误是写成 send(sock, buf, len, 0) 就以为发出去了，其实可能只发了部分；recv() 返回 0 表示对方关闭连接，返回 -1 且 errno == EAGAIN/EWOULDBLOCK 才是暂时没数据——但默认 socket 是阻塞的，所以初学先别设非阻塞，直接按阻塞模式写。
关键点：
立即学习“C++免费学习笔记（深入）”；
-
send()返回值n小于len时，要循环调用，从buf + n开始继续发剩余字节 -
recv()返回值为 0 时，应退出接收线程（对端已断开） - 字符串消息建议以
'\n'结尾，recv()拿到后手动找换行符截取消息，避免粘包（例如连续发 “hi\n” 和 “ok\n”，recv()可能一次读到 “hi\nok\n”）
服务端用 accept() 阻塞等待连接，但一个服务端只能聊一个客户端？
是的，最简版本的服务端每次 accept() 后只处理一个客户端连接，没有多路复用（select/poll/epoll）。这不是缺陷，是刻意简化——先确保单连接稳定，再扩展。如果你硬要支持多个客户端，就得为每个 accept() 到的 client_sock 启动一对收发线程，并用容器存这些 socket 和对应线程句柄。
注意：
- 服务端
bind()前要设SO_REUSEADDR，否则改代码重跑时提示 “Address already in use” - 不要在主线程里直接
recv()客户端消息，必须交给新线程，否则accept()被堵住，无法响应新连接 - 客户端断开后，服务端线程里
recv()返回 0，此时应close(client_sock)并清理线程资源，否则 fd 泄露
编译和运行时踩的坑：g++ 缺链接选项、localhost 解析失败、防火墙拦截
Linux/macOS 下编译服务端必须加 -lpthread（线程）和 -lresolv（域名解析），例如：g++ server.cpp -o server -lpthread -lresolv；Windows 用 MinGW 则要加 -lws2_32。如果客户端连不上 localhost:8080，先用 telnet localhost 8080 测试端口是否真在监听——服务端启动后，用 netstat -tuln | grep 8080 看有没有 LISTEN 状态。
容易忽略的点：
- 服务端绑定
INADDR_ANY（即0.0.0.0）才能被本机其他进程访问，绑127.0.0.1有时会因 IPv6 优先级问题连不上 - macOS 默认开启防火墙，首次运行 socket 程序会弹窗询问是否允许，点“允许”才行
- 消息末尾记得加
'\n'，否则std::getline()在客户端读输入时会一直等，看起来像“卡住”
std::thread 加两个 while(1) 解决，得靠明确的结束信号和 joinable 判断。 
