Java对象序列化网络传输校验和的核心是先对完整序列化字节流计算校验值再发送，接收端先校验后反序列化；校验必须覆盖整个字节流（含头部、类描述等），不可嵌入业务对象字段；推荐协议帧含魔数、版本、数据长度、序列化数据体及校验字段；需流式处理避免内存拷贝，且反序列化前必须校验通过。
Java 对象序列化在网络传输中加入校验和，核心思路是：**不直接对原始对象序列化流做校验，而是对序列化后的字节流整体计算校验值，并将该校验值与数据一同发送；接收端先校验再反序列化**。这样能有效识别传输过程中的字节损坏、截断或篡改，避免因损坏数据触发反序列化异常甚至安全风险。
校验和应加在序列化字节流之后，而非对象字段内
不能把校验逻辑写进业务对象（比如加一个 checksum 字段并实现 Serializable），因为：
- Java 序列化协议本身不保证字段顺序或结构稳定，transient 或 serialVersionUID 变更都可能影响字节布局；
- 校验字段若参与序列化，会成为反序列化后对象的一部分，污染业务语义；
- 真正的完整性校验必须覆盖整个序列化输出——包括头部标记、类描述、字段值、结尾等所有字节。
正确做法是：获取 ObjectOutputStream 写出的完整字节数组（或流式计算），再对其执行累加校验（如 16 位 Additive Checksum）或更健壮的 CRC32。
推荐的传输封装结构（Netty 或自定义协议场景）
以常见二进制协议帧为例，建议采用如下格式：
- 魔数（2 字节）：标识合法包头，如 0xC0FA；
- 版本号（1 字节） + 序列化类型（1 字节，如 0x01 表示 Java 原生）；
- 数据长度（4 字节）：不含魔数、头字段，仅指后续 data + checksum 的总长；
-
序列化数据体（N 字节）：即
ObjectOutputStream输出的完整字节； - 校验字段（2 或 4 字节）：对“数据体”单独计算的累加和（低字节在前）或 CRC32。
服务端收到后，先校验魔数和长度，再截取数据体，计算其校验值，与末尾字段比对一致才进入反序列化流程。
代码关键点：避免内存拷贝，支持流式处理
若对象较大，不建议一次性转成 byte[] 再算校验。可借助 CheckedOutputStream（配合 CRC32）或自定义 ChecksumOutputStream：
- 用
ByteArrayOutputStream包装CheckedOutputStream，再传给ObjectOutputStream； - 写完后调用
getChecksum().getValue()获取校验值； - 最后将 ByteArrayOutputStream 的 buf + 校验值拼成完整报文发送。
示例片段（CRC32）：
byte[] data = ... // 序列化结果CRC32 crc = new CRC32();
crc.update(data, 0, data.length);
int checksum = (int) crc.getValue(); // 或取低 16 位用于累加校验
注意反序列化前必须校验通过
接收端绝不可跳过校验直接调用 ObjectInputStream。哪怕只差 1 字节，也可能导致：
-
StreamCorruptedException或InvalidClassException； - 静默解析错误字段，造成业务逻辑异常；
- 在某些旧 JDK 版本中，甚至触发反序列化 gadget 链误判（虽非主动攻击，但增加不确定性）。
务必在校验失败时丢弃整包、记录告警，并可选关闭连接防止脏数据累积。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
