分包与粘包处理的核心是应用层自定义帧界定：采用固定长度头（4字节int）+变长内容，读取时先readFully头解析length，再readFully正文；禁用BufferedReader/PrintWriter，统一用DataInputStream/DataOutputStream或ByteBuffer；需配合SO_TIMEOUT和心跳机制防阻塞。
在 Java 轻量级聊天室中用 IO 流实现自定义协议时，分包与粘包处理的核心是：**不能依赖网络层自动切分消息，必须在应用层约定边界**。TCP 是字节流协议，一次 write() 可能被拆成多次 read()，也可能多个 write() 合并成一次 read() —— 这就是粘包和拆包的根源。
用固定长度头 + 变长内容做帧界定
这是最常用、最可控的方式。协议格式设计为：4 字节 int 表示正文长度 + 实际字节数的内容（如 UTF-8 编码的 JSON 或纯文本）。服务端/客户端每次读取前先读够 4 字节，解析出 length，再循环读满 length 字节才算一条完整消息。
示例关键逻辑：
- 发送方：先 writeInt(length)，再 write(byte[]) 写内容
- 接收方：用 DataInputStream.readFully(byte[], 0, 4) 读头；调用 readFully(byte[], 0, length) 读正文；避免用 read() 单字节轮询
- 注意：readFully 会阻塞直到读满，适合已知长度场景；若底层 Socket 设置了 SO_TIMEOUT，需捕获 SocketTimeoutException 并重试
用特殊分隔符（如 或 ）但需转义机制
适合文本协议（如简单指令 "LOGIN|user123"），但必须约定转义规则，否则分隔符出现在消息体中会导致误切。例如约定：消息内出现 时写成 \0，接收方解析时反向还原。
立即学习“Java免费学习笔记（深入）”；
操作要点：
- 发送前对正文做 escape（如 replace(" ", "\0")），再拼接
- 接收方用 BufferedReader.readLine() 不可靠（它按 切，且不支持自定义分隔符）；建议用 BufferedInputStream 配合 byte[] 手动扫描，遇到未被转义的 就截断
- 避免用 String.split(" ") 直接切——它无法区分原始 和转义后的 \0
避免直接用 BufferedReader / PrintWriter 处理自定义二进制协议
BufferedReader 是为字符流设计的，内部有缓冲和编码转换，会干扰字节边界；PrintWriter 的 println() 自动加 ，破坏你定义的帧结构。即使协议全是文本，也推荐统一用 DataInputStream/DataOutputStream 或 ByteBuffer + Channel。
正确做法：
- 所有读写走 DataInputStream/DataOutputStream —— 它们提供 readInt()/writeInt()、readUTF()/writeUTF() 等带长度前缀的方法（注意 readUTF 内部用 2 字节存长度，且只支持 modified UTF-8）
- 若用 NIO，用 ByteBuffer.allocateDirect() 配合 SocketChannel.read()，手动维护 position/limit 做粘包判断
- 不要混合使用：比如一边用 DataOutputStream.writeUTF()，另一边用 BufferedReader.readLine() —— 编码、换行、长度前缀全不匹配
心跳与超时保障粘包处理不卡死
仅靠长度头还不够：如果对方异常断连，readFully 可能永远阻塞。必须配合 Socket 层超时和应用层心跳。
- 设置 socket.setSoTimeout(30000) —— read 操作超时抛 IOException，可中断当前帧等待，清理连接
- 服务端定期发 PING，客户端回 PONG；连续几次无响应则主动 close
- 接收缓冲区要累积未处理字节：每次 read 到的 byte[] 追加到一个 List
或 ByteArrayOutputStream，再按协议头不断尝试剥离完整帧，剩余字节留待下次读取
