可行但需规避available()误用：DataInputStream仅封装方法，TCP无消息边界，须用readUTF()或自定义“长度+内容”协议（如readInt()+readFully()）确保完整读取。
直接用 DataInputStream 包装 socket.getInputStream() 是可行的，但必须绕开 available() 做长度判断
DataInputStream 本身不改变底层 TCP 流的行为，它只是给原始 InputStream 加了一层方法封装（比如 readUTF()、readInt()）。真正容易出错的地方在于：很多人误以为 inputStream.available() 能返回「待读消息的完整字节数」——其实它只返回「当前内核缓冲区里已到达且可无阻塞读取的字节数」，在跨网络场景下这个值几乎总是 0 或远小于实际消息长度。
常见错误现象是客户端卡住、只读到半截数据、或抛 EOFException。这是因为 TCP 是字节流，不是消息边界清晰的管道。
- 不要用
inputStream.available()分配缓冲区大小，尤其在广域网或高延迟链路下基本失效 - 不要依赖单次
read(byte[])就读完一整条逻辑消息 - 如果服务器用
writeUTF()发送，客户端必须用readUTF()配对，否则会因前缀长度字段错位而崩溃
用 readUTF() 实现带长度前缀的字符串收发最省事
readUTF() 内部自动处理了「先读 2 字节长度，再读对应字节数」的逻辑，适合传输短文本（≤65535 字节），且要求双方严格使用 UTF-8 编码（Java 默认）。
使用场景：控制台聊天、配置同步、轻量指令（如 "SHUTDOWN"、"PING"）。
- 服务器端发送：
dataOutputStream.writeUTF("Hello from server"); - 客户端接收：
String msg = dataInputStream.readUTF(); // 自动按前缀长度读完，阻塞直到收齐
- 注意：如果对方没用
writeUTF()，而用writeBytes()或裸write()，调用readUTF()会立即失败（读到非预期的长度头）
需要读任意长度二进制数据时，必须自己实现“长度+内容”协议
TCP 不保证消息边界，所以你得在应用层补上。最简方案是固定 4 字节 int 表示后续 payload 长度（兼容性好，DataInputStream.readInt() 直接可用）：
- 服务器发送顺序：
dataOutputStream.writeInt(payload.length);dataOutputStream.write(payload); - 客户端接收逻辑：
int len = dataInputStream.readInt(); // 阻塞直到读够 4 字节<br>byte[] buf = new byte[len];<br>dataInputStream.readFully(buf); // readFully 保证读满，不会提前返回
- 关键点：
- 必须用
readFully()，不能用普通read()，否则可能只读到部分数据 -
readInt()按网络字节序（大端）读，Java 默认一致，无需额外转换 - 如果 payload 可能超 2GB，改用
long+readLong()，但需双方约定
- 必须用
别忽略 Socket 关闭和异常时的数据残留问题
网络中断、对方进程崩溃、防火墙静默丢包都会导致 DataInputStream 在读取中途抛异常（IOException 或 SocketException）。此时缓冲区里可能已有部分数据，但没被消费。
- 不要在 catch 块里直接忽略异常后继续循环读，容易把上次残留的半包当新消息解析
- 建议在每次逻辑消息处理前加校验（如 TLV 中的 type 字段是否合法、length 是否在合理范围）
- 生产环境务必设置
socket.setSoTimeout(30000)，避免无限阻塞；超时后应重连或清空状态
跨网络读取真正的难点从来不在 DataInputStream 本身，而在于你怎么定义“一条消息”的边界——这决定了你写多少协议逻辑、容错多强、能不能扛住丢包和乱序。
