Java序列化二进制流开头固定为0xACED0005，其中ACED是ObjectStreamConstants.STREAM_MAGIC魔数（标识合法序列化流起点），0005是STREAM_VERSION协议版本号（固定为5），用于反序列化时校验格式合法性并指导后续字节解析。
Java 对象序列化二进制流开头的 0xACED 不是随意写的字节，而是有明确定义的协议标识——它就是 ObjectStreamConstants.STREAM_MAGIC 的十六进制表示；紧随其后的 0x0005（即十进制 5）则是 STREAM_VERSION，代表当前使用的序列化协议版本。
魔数 0xACED 的作用：标记合法序列化流起点
魔数（Magic Number）本质是一个“签名”，用于快速识别数据格式。在 Java 序列化中：
-
STREAM_MAGIC = (short) 0xaced是固定值，占 2 字节（高位在前，即先写0xAC，再写0xED） - 反序列化时，
ObjectInputStream会首先读取这 2 字节，若不匹配就直接抛出StreamCorruptedException - 它的存在不是为了加密或校验，而是防止把非序列化数据误当作对象流解析
- 类似 HTTP 协议以
HTTP/开头、PNG 图像以89 50 4E 47开头，属于协议层面的“握手信号”
版本号 0x0005 的含义：协议结构的兼容性锚点
STREAM_VERSION = 5 同样占 2 字节（因此实际看到的是 0x00 0x05），它说明：
- 这是 JDK 1.2 引入并沿用至今的序列化协议版本（JDK 1.1 起始即为 v5，未变更过）
- 版本号影响类描述符（
TC_CLASSDESC）、字段编码规则、块数据边界（TC_ENDBLOCKDATA）等底层布局 - 不同 JVM 实现必须按此版本解释后续字节，否则无法正确重建对象图
- 注意：它和类自身的
serialVersionUID无关——后者控制类定义变更时的兼容性，而STREAM_VERSION控制序列化格式本身的语义
为什么在 Redis 或日志里常看到 \xac\xed\x00\x05？
当你在 Redis 中存一个 Java 对象（如用 StringRedisTemplate 但底层用了默认 JdkSerializationRedisSerializer），或者用十六进制工具打开 .ser 文件时，开头大概率是这 4 字节：
-
\xac\xed→STREAM_MAGIC -
\x00\x05→STREAM_VERSION（因是short类型，高位补零） - 接下来通常是
TC_OBJECT（0x73）或TC_STRING（0x74）等 tag，标志着真正数据内容开始 - 这类“乱码前缀”正是 Java 序列化协议的指纹，也是排查跨语言/跨框架数据互通问题的第一线索
绕过魔数与版本号的常见场景
某些安全或性能敏感场景会主动避开标准序列化协议：
- 使用
Externalizable接口自定义writeExternal/readExternal，可完全跳过STREAM_MAGIC和类描述结构 - 选用 Kryo、FST、Protobuf 等替代方案，它们有自己的魔数（如 Protobuf 没魔数，Kryo 默认是
0x5243） - Spring Session 或 RedisTemplate 配置
GenericJackson2JsonRedisSerializer，输出的是 JSON 字符串，自然没有0xACED - 手动调用
writeInt/writeUTF等基础方法写入流，不触发ObjectOutputStream的协议头写入逻辑
