Java Socket传输本质是字节流通信，TCP只保证字节顺序和可靠性，不关心数据含义；必须用InputStream/OutputStream收发原始数据，字符流仅适用于编码明确的纯文本场景，误用会导致乱码、截断或阻塞。
Java 中 Socket 传输本质是字节流通信，TCP 不关心数据含义，只保证字节顺序和可靠性。因此，必须用字节流（InputStream / OutputStream）收发原始数据；字符流（如 InputStreamReader / PrintWriter）仅适合纯文本且编码明确的场景，误用会导致乱码、截断或阻塞。
为什么不能直接用字符流传文件或二进制数据
字符流会按指定编码（如 UTF-8）将字节解码为 char，而文件、图片、序列化对象等本身不含编码语义。例如：
- 一个 PNG 文件头是
89 50 4E 47，UTF-8 解码可能在89处失败或转成无效字符； -
BufferedReader.readLine()依赖换行符，但二进制数据中可能恰好含0A，导致提前截断； - 字符流内部缓冲机制与 TCP 实际分段不一致，容易引发粘包/半包判断失效。
字节流高效收发的核心要点
关键不是“快”，而是可控、完整、可恢复。推荐做法包括：
- 始终使用带缓冲的字节流：如
BufferedInputStream包装socket.getInputStream()，减少系统调用次数； - 每次
read()必须检查返回值：int n = in.read(buf)，仅当n > 0才写入目标；n == 0不代表结束，需继续读；n == -1才表示对端关闭连接； - 发送定长头部 + 变长载荷：例如先写 4 字节 int 表示文件长度，再写对应字节数的文件体，接收端严格按此协议读取，避免粘包；
- 大文件分块传输：单次
read()不要依赖“读满整个 buffer”，而应循环读直到凑够所需字节数（如头部长度、文件剩余长度）。
何时可以安全用字符流
仅限于以下情况：
- 双方约定纯文本协议，且明确编码（如统一 UTF-8）；
- 每条消息以换行符或固定分隔符结尾（如 HTTP 的
\r\n），且内容本身不含该分隔符； - 使用
PrintWriter发送后调用flush()，接收端用BufferedReader.readLine()配合超时控制； - 不用于传输任意二进制数据、文件、序列化对象或加密内容。
一个典型可靠写法示例（服务端接收文件）
不用字符流，不依赖 readLine()：
- 先读 4 字节 → 转成
int len（文件总大小）； - 再循环读，每次最多读
Math.min(8192, 剩余字节数)，累计写入FileOutputStream； - 每次
read()后校验返回值，遇到-1立即抛异常（连接异常中断）； - 全部读完后，用
MessageDigest计算 MD5 并与客户端发来的校验值比对。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
