go 客户端无法收到 java 服务端回显，根本原因是 java 服务端使用 bufferedreader.readline() 等待带换行符（\n 或 \r\n）的完整行，而 go 客户端未发送换行符，导致服务端阻塞在读取操作中。
要使 Java Echo Server 正确响应 Go 客户端，关键在于协议对齐：Java 服务端依赖 readLine()，该方法会一直阻塞，直到读取到行终止符（LF \n 或 CRLF \r\n）；而当前 Go 客户端仅发送 "Hello" 字节流，不包含任何换行符，因此服务端永远无法完成一次 readLine() 调用，自然也不会执行 out.println(s) 回复逻辑。
✅ 正确做法是：在 Go 客户端发送的字符串末尾显式添加换行符。例如：
strEcho := "Hello\n" // ✅ 关键修复：添加 \n _, err = conn.Write([]byte(strEcho))
此外，还需注意以下几点以确保稳定通信：
-
服务端应避免过早关闭连接：当前 Java 代码中 in.readLine() 在客户端未发送换行符或主动断开时会返回 null，但若客户端只发一次消息后不关闭连接，服务端循环仍可能卡住。建议增加超时或明确结束机制；
立即学习“Java免费学习笔记（深入）”；
-
客户端需处理读取的字节数与空字符：conn.Read(reply) 返回实际读取字节数，应截取有效内容，避免打印残留的零值字节：
n, err := conn.Read(reply) if err != nil { println("Read from server failed:", err.Error()) os.Exit(1) } println("reply from server =", string(reply[:n])) // ✅ 使用 [:n] 截取真实响应 可选增强：服务端添加写入刷新（虽 PrintWriter 构造时启用 auto-flush，但显式 out.flush() 更健壮）；客户端可设置读取超时防止永久阻塞。
总结：TCP 是字节流协议，应用层需约定消息边界。readLine() 隐含了“按行解析”的语义，要求发送方严格遵守——每条消息必须以换行符结尾。这是跨语言网络编程中极易被忽视却至关重要的细节。
