Socket.getInputStream()返回的InputStream本身不带缓冲和超时控制，必须配合BufferedInputStream或按协议约定读取；read()默认阻塞直至有数据到达或对方关闭连接才返回-1，未设setSoTimeout则无限等待。
直接说结论：Socket.getInputStream() 返回的 InputStream 本身不带缓冲和超时控制，必须配合 BufferedInputStream 或 read() / read(byte[]) 的具体调用方式才能稳定读取服务端数据；裸调用 read() 容易卡死或漏读。
为什么 read() 会一直阻塞？
默认情况下，Socket 是阻塞模式，InputStream.read() 会等到至少一个字节到达才返回 —— 如果服务端没发、发得慢、或只发了半包，客户端就卡在那儿不动了。
- 检查是否设置了
socket.setSoTimeout(5000)，否则read()不会抛SocketTimeoutException，而是无限等 - 服务端关闭连接时，
read()才返回-1；仅写完数据不关流，客户端无法感知“消息结束” - 不要依赖
available()判断是否有数据 —— 它在 TCP 层不可靠，常返回 0 即使数据已在内核缓冲区
怎么安全读完一整条响应（比如 HTTP 或自定义协议）？
不能只靠单次 read()，得根据协议约定识别边界。常见做法：
- 若服务端每条消息以换行符结尾（如
"\n"或"\r\n"），用BufferedReader.readLine()最省心（注意编码要和服务端一致，比如new BufferedReader(new InputStreamReader(in, "UTF-8"))） - 若消息固定长度（如前 4 字节是 int 表示 body 长度），先读够头，再按长度读 body：
int len = ByteBuffer.wrap(headBuf).getInt(); in.read(fullBody, 0, len); - 若用分隔符（如
"\0"），手动循环read()到缓冲区，边读边扫描，避免一次性read(byte[])读超长导致 OOM
BufferedInputStream 真的能加速吗？
它不提升网络吞吐，但减少系统调用次数，对小包频繁读场景明显改善。不过要注意：
-
BufferedInputStream的缓冲区大小默认 8192 字节，如果单次消息普遍 >8KB，建议显式指定更大值：new BufferedInputStream(in, 64 * 1024) - 它会把“已从内核读出但未被应用消费”的数据缓存在用户空间，所以
available()在包装后可能返回非零值 —— 但这仍是估算，不能用于流程控制 - 如果服务端发的是流式数据（如日志推送），且你希望低延迟处理每小块，反而应绕过
BufferedInputStream，直接用read(byte[], off, len)控制粒度
最易被忽略的一点：TCP 是字节流，没有天然消息边界。无论用什么包装，都得靠协议层约定来切分数据 —— InputStream 只负责“字节来了没”，不负责“这算不算一条完整消息”。
