std::cout 直接写远程会卡死或丢日志，因 stdout 缓冲机制与 tcp 阻塞 send 导致；需非阻塞 socket、自定义缓冲批量发送、禁用 endl、加长度头或分隔符、心跳保活、正确处理 send 返回值及本地落盘+ack 保障可靠性。
为什么 std::cout 直接写远程会卡死或丢日志
因为标准输出是行缓冲或全缓冲的，std::cout 写入后不一定会立刻发出去；更关键的是，TCP 连接一旦阻塞（比如远程服务器暂时不可达、网络抖动），默认 socket 是阻塞模式，send() 会挂住整个主线程——你看到的现象通常是程序“突然不动了”或者日志断在某一行。
- 必须把 socket 设为非阻塞模式，或用
select()/poll()控制发送时机 - 日志不能直接
operator 到 socket 流，得自己做缓冲 + 批量发送，否则小包太多，网络开销爆炸 - 别用
std::endl，它强制 flush + 换行，容易触发频繁 send，改用"\n" - 远程服务端没做好粘包处理？那客户端发的多条日志可能被合并成一坨，或截断——必须加长度头或分隔符
用 send() 发日志前必须检查的三件事
不是调了 send() 就等于发成功了。返回值可能小于请求长度，也可能返回 -1 并设 errno，尤其在非阻塞 socket 下极常见。
- 检查返回值：
int n = send(sockfd, buf, len, 0);，若n > 0表示发了n字节，要记录偏移继续发剩余部分 - 若
n == 0：对端已关闭连接，该清理 socket 并重连 - 若
n == -1：查errno，EAGAIN或EWOULDBLOCK表示当前不可发，需等可写事件；ECONNRESET/ENOTCONN表示连接已断
setsockopt(sockfd, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) 真的够用吗
不够。SO_KEEPALIVE 只能探测连接是否“物理存活”，但无法感知应用层断连（比如服务端进程崩溃但 TCP 连接未四次挥手）。实际中更可靠的做法是加心跳帧 + 超时重连。
- 每 30 秒发一个轻量心跳包（如
"PING\n"），服务端回"PONG\n" - 连续 2 次心跳超时（比如 5 秒没收到 PONG），就 close 当前 socket，启动重连逻辑
- 重连间隔要指数退避，比如 1s → 2s → 4s，避免雪崩式重连打爆服务端
- 别在日志线程里直接
connect()，阻塞太久；用非阻塞 connect +select()等可写事件判断是否连上
日志格式不加长度头，服务端根本没法安全解析
TCP 是字节流，没有消息边界。你 send("A\n") 和 send("B\n") 在接收端可能被合并在一次 recv() 里拿到 "A\nB\n"，也可能被拆成 "A\nB" 和 "\n"——不靠协议约定，服务端永远不知道一条日志在哪结束。
- 推荐固定头 + 内容格式：
[4-byte-len][content]，先send()4 字节网络序长度，再发内容 - 或者用特殊分隔符，但必须确保日志内容里不会出现该分隔符（比如用
"\0"结尾，配合send(..., MSG_NOSIGNAL)） - 别依赖换行符做分割——用户日志里打个堆栈，几十行带 \n 的字符串就直接让解析器歇菜
- 服务端 recv 时必须循环读满指定长度，不能只调一次
recv()就认为收完了
真正麻烦的从来不是怎么发，而是怎么确保每条日志在断网、重连、缓冲区溢出、服务端重启这些情况下，既不重复也不丢失——这得靠客户端本地落盘暂存 + ACK 机制，不是 socket 配置能解决的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
