DataInputStream读int卡住或读错，因其严格按大端序读4字节，若写入非DataOutputStream、流截断或对齐错位，会导致阻塞、错误值（如-16909060）或EOFException；必须配对使用DataOutputStream，注意缓冲区flush和字节序兼容性。
为什么 DataInputStream 读 int 会卡住或读错？
因为底层依赖字节序（big-endian）且严格按固定长度读取，一旦写入端不是用 DataOutputStream 写的，或者流被提前截断、对齐错位，readInt() 就会阻塞等待剩余 4 字节，或把前几个字节拼成错误值。
- 常见错误现象：
readInt()阻塞在 socket 流中；读出-16909060这类明显异常的整数；EOFException突然抛出 - 必须配套使用：
DataOutputStream写，DataInputStream读 —— 它们共享同一套二进制协议，不兼容ObjectOutputStream或自定义 byte[] 拼接 - 注意缓冲区边界：如果上层用了
BufferedInputStream，但没调用flush()，DataOutputStream可能只写了部分字节，DataInputStream就会等不到完整int - 示例：写入
dos.writeInt(256)，底层一定是0x00 0x00 0x01 0x00（大端），读时也必须按此顺序解析
DataOutputStream.writeUTF() 和普通字符串写入的区别在哪？
它不是直接写字符串字节，而是先写 2 字节长度（short），再写 UTF-8 编码内容 —— 所以能安全跨平台读回，但要求长度 ≤ 65535 字节，且不支持 surrogate pair 的完整 Unicode 表达（如某些 emoji）。
- 容易踩的坑：
writeUTF("a".repeat(70000))会抛UTFDataFormatException，因为长度超0xFFFF - 和
writeBytes()完全不同：writeBytes()不写长度头，也不转 UTF-8，遇到非 ASCII 字符会丢高字节，基本只适合 ASCII 场景 - 性能影响：比直接写
String.getBytes(StandardCharsets.UTF_8)多一次长度计算 + 2 字节开销，小字符串差异不大，高频写长文本时可考虑绕过 - 读端必须用
readUTF()，否则手动跳过长度头容易错位，后续所有读操作都会偏移
跨平台时字节序和类型大小真的一致吗？
Java 规范强制 DataInputStream/DataOutputStream 使用 big-endian 和固定宽度（int 总是 4 字节，double 总是 8 字节），所以只要两端都是标准 JVM 实现，就不存在字节序或类型大小问题 —— 但 C/C++ 或 Python 的 struct 模块默认可能是 little-endian，这时必须显式指定 >（big）模式。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 典型兼容场景：Java 服务写
dos.writeLong(System.currentTimeMillis())，Python 用struct.unpack('>Q', data)读，不能用<q></q> - 注意浮点精度：
float/double按 IEEE 754 存储，Java 和主流语言一致，但某些嵌入式平台或旧系统可能用非标准实现（极少见） - 别信“本地平台”：即使在 x86 Linux 上跑 Java，
DataOutputStream依然输出 big-endian —— 它不看 CPU，只认 Java 规范
不用 DataInputStream，还有更稳的原始类型序列化方案吗？
有，但要看场景：如果只是 Java 内部通信，ByteBuffer（配合 order(ByteOrder.BIG_ENDIAN)）更轻量、无流阻塞风险；如果要跨语言，Protocol Buffers 或 FlatBuffers 更可靠，它们自带 schema 和版本管理，而 DataInputStream 是裸协议，字段增删改极易导致运行时错位。
立即学习“Java免费学习笔记（深入）”；
-
ByteBuffer优势：可重复读写、位置可控、不依赖流状态，适合内存内数据打包 - 陷阱：
DataInputStream的readLine()已废弃且行为诡异（只识别\n，不处理\r\n），绝对不要用，改用BufferedReader - 真正容易被忽略的一点：
DataInputStream本身不缓冲，每次readXxx()都可能触发底层 I/O —— 如果频繁读小数据，包一层BufferedInputStream能显著提升性能，但记得 flush 对应的BufferedOutputStream
