怎么利用 DataOutputStream 按照平台无关顺序写入基本数据

DataOutputStream 的 writeInt()、writeDouble() 等方法严格按大端序和 IEEE 754/补码标准编码，保证平台无关；writeUTF() 与 readUTF() 必须配对使用；必须包装 FileOutputStream，且需 close 或 try-with-resources 确保落盘。 writeInt() 和 writeDouble() 这类方法天然保证平台无关 DataOutputStream 的 、 、 等方法内部已固化字节序（大端序）和编码规则，无需手动处理字节序或类型对齐。只要用它写，就是平台无关的——不是“尽量做到”，而是 Java 规范强制要求。 关键点在于：它不依赖本地 CPU 字节序，也不受 JVM 实现影响； 在 x86 和 ARM 机器上都写成 四个字节。 所有数值类型均按 IEEE 754（float/double）或二进制补码（int/long）标准编码 写的是 UTF-16 码点高字节在前，不是字符编码意义上的“UTF-8” 是 DataInputStream 专用格式：先写 2 字节长度（大端），再写 UTF-8 字节——不能用普通文本工具看，也不能用 读 必须包装 FileOutputStream，不能直接 new DataOutputStream("file.dat") 是装饰器流，没有文件操作能力。试图传入字符串路径会编译失败——它只接受 子类实例。 常见错误写法： → 编译报错：no suitable constructor。 CentOS Stream 9 CentOS Stream 9是基于RHEL 9技术路线的持续交付版本，适合需要贴近RHEL 9生态的软件开发、系统集成和测试环境。它相比传统CentOS Linux更靠近上游开发过程，用户可以更早看到RHEL 9后续小版本中的软件包变化。CentOS Stream 9仍是当前可用的官方版本线之一，适合对稳定性和新功能之间有平衡需求的团队使用。 下载 正确路径：先建 ，再套一层 如果目标目录不存在（如 ）， 会抛 ，需提前确保父目录存在 使用 构造函数可控制是否追加，但 本身无追加逻辑 writeUTF() 和 readUTF() 必须严格配对，混用 writeBytes() 就乱码 写出的是：2 字节长度（0x00 0x06）+ 6 字节 UTF-8 编码（ ）；而 直接按平台默认编码（如 GBK）写入字节，长度不可预知， 会误读前两个字节为长度，导致后续全错。 写字符串必须用 ，读必须用 不要用 （写 UTF-16BE，每个字符占 2 字节，含 \0） 如果要存纯 ASCII 字符串且长度固定，可用 + ，但失去自动长度标记 资源不 close 或不 try-with-resources 会导致数据没真正落盘 有内部缓冲区，默认大小 8192 字节。 等调用只是把数据塞进缓冲区，不调 或 ，操作系统可能根本没收到写请求——尤其小数据（如只写一个 int）时极易丢失。 推荐始终用 try-with-resources： 手动管理时， 会隐式调用 ；单独 不释放底层文件句柄 若中途异常，未 close 的流可能让文件句柄泄漏，Linux 下容易触发 “Too many open files” 写入顺序和类型必须与后续 的读取逻辑一字不差，哪怕多一个 或少一个 ，后面所有字段都会偏移错位——这种错误不会报异常，只会读出完全不可理解的值。