title: 一个 JsonIgnore 漏写把用户密码序列化到了前端序列化选型的 4 个真实坑topic: 序列化框架对比Protobuf、JSON、Hessianbatch: 6round: 3我们用户服务把User对象直接JSON.toJSONString丢给前端DTO 里图省事复用了实体类结果安全审计发现用户密码字段password虽然加密存储但仍是敏感串被序列化进了接口响应前端 network 里明文可见。原因很简单——忘了在字段上加JsonIgnore。序列化看着只是「对象变字节」但它牵扯安全、兼容、性能三件大事选错框架或写错注解坑比你想的深。这篇文章用 4 个真实事故把 JSON、Protobuf、Hessian 怎么选、各自的雷讲清楚。事故一Jackson 漏 JsonIgnore敏感字段出网最早的用户返回简化public class User { private Long id; private String name; private String password; // 加密后的密码仍属敏感 private String idCard; // 身份证号 // getters/setters } // Controller 里直接返回实体 GetMapping(/user/{id}) public User getUser(PathVariable Long id) { return userService.load(id); // 整对象序列化出去 }逐行解释为什么这是安全事故- 第 4 行password、第 5 行idCard是敏感字段但User没加任何 Jackson 注解默认所有 getter 对应的字段都会被序列化进 JSON。前端拿到的响应里赫然有password和idCard。- 更隐蔽的我们用了 LombokData自动生成 getterJackson 按 getter 序列化你以为「字段是 private 就安全」其实序列化看的是 getter 不是字段可见性。这是最常见的误解。- 第 11 行直接return userService.load(id)把「数据库实体」当「接口响应」——实体里有什么敏感字段全暴露。正确做法是单独建 Response DTO只映射要暴露的字段。修法单独 DTO 显式忽略public class UserResponse { private Long id; private String name; // 只放允许出网的字段password/idCard 根本不进这个类 } GetMapping(/user/{id}) public UserResponse getUser(PathVariable Long id) { User u userService.load(id); UserResponse r new UserResponse(); r.setId(u.getId()); r.setName(u.getName()); return r; // 序列化的就是干净的 DTO }逐行解释- 第 2 行UserResponse是「只含白名单字段」的响应对象敏感字段物理上不存在于这个类里从根上杜绝泄露——比「加 JsonIgnore」更稳因为后者哪天有人改实体加敏感字段又忘写注解照样漏。- 第 10-11 行手动映射虽然啰嗦但「出网字段是显式声明出来的」review 一眼能看到。我们后来强制规定所有对外响应必须走 DTO禁止实体直接出网这条规则挡掉了不止一次类似泄露。- 如果你坚持复用实体至少用JsonIgnore或JsonProperty(access WRITE_ONLY)标敏感字段但 DTO 分离是更彻底的解法。事故二LocalDateTime 默认序列化丢时区对账差 8 小时我们订单的创建时间用LocalDateTime序列化到 JSON 后是2026-08-15T13:20:00没有时区。下游对账系统按 UTC 解析结果时间全偏了 8 小时一天的对账差了几百万金额的对不齐。public class Order { private LocalDateTime createTime; // 没有时区信息 // ... } // Jackson 默认把 LocalDateTime 序列化成 ISO 无时区串 String json objectMapper.writeValueAsString(order); // 输出: {createTime:2026-08-15T13:20:00}逐行解释- 第 2 行LocalDateTime本身不带时区Jackson 默认按yyyy-MM-ddTHH:mm:ss输出没有 offset。接收方不知道这是北京时间还是 UTC按自己默认时区解析就错。- 第 6 行输出的字符串「看着对」实则丢失了「这是哪个时区的时间」这个关键信息。跨系统传递时间缺时区就是埋雷。- 修法二选一要么实体用OffsetDateTime/ZonedDateTime自带时区Jackson 输出带08:00要么全局配置objectMapper.setTimeZone(TimeZone.getTimeZone(Asia/Shanghai))并注册JavaTimeModule让序列化带上时区。我们用的是前者——时间类型本身就该带时区别靠约定。事故三Hessian 序列化 BigDecimal精度在跨语言时丢了一分钱我们用 Hessian2 做 RPCDubbo 默认有个金额字段BigDecimalJava 侧算出来是100.00Go 侧反序列化后变成100.0虽然数值相等但我们对账按「字符串精确比对」直接判不一致几千笔订单对不上。// Java 侧用 Hessian2 序列化 BigDecimal Hessian2Output out new Hessian2Output(os); out.writeObject(new BigDecimal(100.00)); // 精度 100.00 out.flush(); // Go 侧 hessian 库反序列化变成 100.0scale 信息在跨语言实现里不一致逐行解释- 第 3 行new BigDecimal(100.00)的scale是 2两位小数但 Hessian 的BigDecimal序列化在不同语言的实现里对scale的处理不完全一致Go 的 hessian 库解出来变成scale为 1 的100.0。数值一样但「字符串表示」不同。- 这不是 Hessian 的 bug是「浮点/小数跨语言序列化时精度表示依赖双方实现一致」的普遍坑。我们踩在「对账按字符串比」这个错误假设上。- 修法金额这类对精度敏感的字段要么统一用「最小货币单位的长整数」如分传输彻底绕开小数要么序列化前格式化成固定小数位的字符串。我们最终把金额 RPC 字段改成long cents分一了百了。三个框架怎么选一张对比表框架体积速度可读性/调试跨语言典型雷JSON (Jackson)大中好人能读好文本敏感字段泄露、时间时区、null 语义Protobuf小极快差二进制好强 schema字段编号变更不兼容、unknown fieldHessian2中快中一般Java 生态最佳跨语言精度/类型不一致、字段顺序我的取舍对外 HTTP 接口、要人读要调试 → JSON 没跑内部 RPC 追求体积和速度、且多方言服务 → Protobuf但 schema 治理要跟上纯 Java 技术栈内部调用、想比 JSON 快又不想写 proto → Hessian2但别用它传跨语言的金额/小数。选型别只看「快不快」要看「你的数据语义在哪个框架上最不容易出错」。第四个坑JDK 原生序列化做缓存加个字段就全炸我们有个临时方案把对象用 JDK 原生ObjectOutputStream写进 Redis 做缓存后来给实体加了一个字段老缓存反序列化直接InvalidClassException——因为 JDK 原生序列化依赖自动生成的serialVersionUID类结构一变就不兼容。public class CacheObject implements Serializable { private String a; private int b; // 没显式声明 serialVersionUIDJDK 按字段结构算 } // 后来加了 private long c; 老缓存反序列化 // java.io.InvalidClassException: 序列化 ID 不一致逐行解释- 第 1 行implements Serializable但没声明serialVersionUIDJDK 会根据「类名 字段 方法签名」算一个 hash 当版本号。你加一个字段hash 变了老数据反序列化直接抛异常。- 这比 Protobuf/Hessian 都脆后者靠「字段编号/名字」做兼容老数据缺字段能给默认值JDK 原生序列化是「结构必须完全一致」几乎零向前兼容。- 修法缓存别用 JDK 原生序列化。我们换成 JSONRedis 里人也能读、加字段兼容或 Kryo/Hessian。如果非用必须显式声明serialVersionUID并把它当「契约」管理——但我们直接弃用了原生序列化因为它在缓存这种「新旧数据共存」的场景里天然不合适。复盘真实数字JsonIgnore漏写事件安全审计一次性扫出 3 个接口把password/idCard/token序列化出网修复后纳入「DTO 白名单」强制规范。LocalDateTime时区问题一天对账差异金额约 300 万其实是时区错位非真差统一OffsetDateTime后差异归零。HessianBigDecimal跨语言约 4200 笔订单因 scale 不一致对账失败金额改long cents后清零。JDK 原生序列化缓存一次实体加字段导致缓存命中率从 92% 掉到 40%大量反序列化失败回源换 JSON 后恢复。我的取舍序列化先看「数据语义」再看性能我不建议用 JDK 原生序列化做任何跨版本的存储/缓存——它的兼容性脆弱到不配出现在生产缓存里。对外接口用 JSON但必须走 DTO 白名单 时间带时区敏感字段物理隔离比加注解更稳。内部 RPC 要速度上 Protobuf但把「字段编号」当 API 版本管别随便重用编号要省事且纯 Java 用 Hessian2但金额/小数别靠它的跨语言精度。一句话序列化框架选错坑在「兼容性」和「安全」上不止在「慢一点」——这俩比那点性能差异贵得多。思考题如果你要设计一个「新旧版本服务长期共存、缓存数据要互相读」的系统你会选哪种序列化为什么 JSON 在缓存场景的「向前兼容」反而比 Protobuf 更省心