tcp echo 通信中 java 服务端与 go 客户端的换行符同步问题解析
在构建跨语言 TCP Echo 系统时，看似简单的“发-回显-收”流程常因协议细节不一致而失败。本例中，Java 服务端能正常接受连接并打印日志，但 Go 客户端在 conn.Read() 处永久阻塞——根本原因在于 行读取（line-oriented I/O）与原始字节流之间的语义错配。
Java 服务端关键代码：
BufferedReader in = new BufferedReader(new InputStreamReader(clientSocket.getInputStream()));
String s;
while ((s = in.readLine()) != null) { // ← 阻塞直到遇到 '\n'、'\r\n' 或流关闭
out.println(s); // 自动追加 '\n'
System.out.println(s);
}readLine() 不是读取任意字节，而是按行边界读取：它会持续缓冲输入，直到遇到换行符（\n）、回车换行（\r\n）或输入流关闭。若客户端未发送换行符，该方法将永不返回，导致后续 out.println(s) 无法执行，自然也就没有响应返回给客户端。
而 Go 客户端当前发送的是纯字符串：
立即学习“Java免费学习笔记（深入）”；
本文档主要讲述的是Android数据格式解析对象JSON用法；JSON可以将Java对象转成json格式的字符串，可以将json字符串转换成Java。比XML更轻量级，Json使用起来比较轻便和简单。JSON数据格式，在Android中被广泛运用于客户端和服务器通信，在网络数据传输与解析时非常方便。希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
strEcho := "Hello" _, err = conn.Write([]byte(strEcho)) // ← 仅发送 "Hello"，无换行符
服务端因此卡在 in.readLine()，整个循环停滞，out.println() 从未触发，客户端 conn.Read() 也就永远等不到数据。
✅ 正确做法：让客户端发送带换行符的消息，与服务端 readLine() 的期望严格对齐：
strEcho := "Hello\n" // 显式添加 '\n' // 或更健壮地使用 "\r\n"（兼容 Windows 行尾） // strEcho := "Hello\r\n" _, err = conn.Write([]byte(strEcho))
⚠️ 注意事项：
- PrintWriter.println() 在服务端会自动追加平台默认换行符（Linux/macOS 为 \n，Windows 为 \r\n），因此客户端只需发送 \n 即可匹配大多数环境；
- 若需更高兼容性，建议服务端统一使用 new PrintWriter(out, true) 并明确用 out.print(s + "\n") 替代 out.println(s)，避免平台差异；
- Go 客户端 conn.Read(reply) 是阻塞式读取，且未指定读取长度边界，建议增加超时控制和长度校验：
conn.SetReadDeadline(time.Now().Add(5 * time.Second)) n, err := conn.Read(reply) if err != nil { log.Fatal("Read failed:", err) } println("reply from server =", string(reply[:n])) // 仅打印实际读到的字节数
总结：TCP 是字节流协议，但 readLine() 引入了应用层的“行”抽象。跨语言开发时，必须显式对齐两端的协议约定——此处即 客户端负责提供行终止符，服务端负责消费并原样回传。忽略这一细节，是 Echo 服务调试中最常见却最易被忽视的陷阱。
