企业官网建设流程全解析

title: 一个 @JsonIgnore 漏写，把用户密码序列化到了前端：序列化选型的 4 个真实坑
topic: 序列化框架对比：Protobuf、JSON、Hessian
batch: 6
round: 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。
- 更隐蔽的：我们用了 Lombok@Data自动生成 getter，Jackson 按 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-dd'T'HH:mm:ss输出，没有 offset。接收方不知道这是北京时间还是 UTC，按自己默认时区解析就错。
- 第 6 行输出的字符串「看着对」，实则丢失了「这是哪个时区的时间」这个关键信息。跨系统传递时间，缺时区就是埋雷。
- 修法二选一：要么实体用OffsetDateTime/ZonedDateTime（自带时区，Jackson 输出带+08:00），要么全局配置objectMapper.setTimeZone(TimeZone.getTimeZone("Asia/Shanghai"))并注册JavaTimeModule，让序列化带上时区。我们用的是前者——时间类型本身就该带时区，别靠约定。

事故三：Hessian 序列化 BigDecimal，精度在跨语言时丢了一分钱

我们用 Hessian2 做 RPC（Dubbo 默认），有个金额字段BigDecimal，Java 侧算出来是100.00，Go 侧反序列化后变成100.0，虽然数值相等，但我们对账按「字符串精确比对」，直接判不一致，几千笔订单对不上。

// Java 侧用 Hessian2 序列化 BigDecimal Hessian2Output out = new Hessian2Output(os); out.writeObject(new BigDecimal("100.00")); // 精度 100.00 out.flush(); // Go 侧 hessian 库反序列化：变成 100.0，scale 信息在跨语言实现里不一致

逐行解释：
- 第 3 行new BigDecimal("100.00")的scale是 2（两位小数），但 Hessian 的BigDecimal序列化在不同语言的实现里对scale的处理不完全一致，Go 的 hessian 库解出来变成scale为 1 的100.0。数值一样，但「字符串表示」不同。
- 这不是 Hessian 的 bug，是「浮点/小数跨语言序列化时，精度表示依赖双方实现一致」的普遍坑。我们踩在「对账按字符串比」这个错误假设上。
- 修法：金额这类对精度敏感的字段，要么统一用「最小货币单位的长整数」（如分）传输，彻底绕开小数；要么序列化前格式化成固定小数位的字符串。我们最终把金额 RPC 字段改成long cents（分），一了百了。

三个框架怎么选：一张对比表

我的取舍：对外 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; // 没显式声明 serialVersionUID，JDK 按字段结构算 } // 后来加了 private long c; 老缓存反序列化： // java.io.InvalidClassException: 序列化 ID 不一致

逐行解释：
- 第 1 行implements Serializable但没声明serialVersionUID，JDK 会根据「类名 + 字段 + 方法签名」算一个 hash 当版本号。你加一个字段，hash 变了，老数据反序列化直接抛异常。
- 这比 Protobuf/Hessian 都脆：后者靠「字段编号/名字」做兼容，老数据缺字段能给默认值；JDK 原生序列化是「结构必须完全一致」，几乎零向前兼容。
- 修法：缓存别用 JDK 原生序列化。我们换成 JSON（Redis 里人也能读、加字段兼容）或 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 更省心？