Fastjson安全模式(SafeMode)开启后，我的老项目代码怎么改？一个真实重构案例分享

Fastjson安全模式重构实战：当老项目遇上SafeMode

接手一个运行了五年的Java消息处理系统时，我从未想过会因为一个JSON库的配置变更引发如此剧烈的代码地震。这个系统里遍布着这样的代码片段：

Message message = JSON.parseObject(jsonStr, Message.class);

表面看只是普通的反序列化，直到安全团队强制要求开启Fastjson的SafeMode——所有依赖@type动态反序列化的功能瞬间崩溃。控制台里刷屏的autoType not support错误提示，像在嘲笑我们对技术债的视而不见。

1. 诊断系统对AutoType的依赖程度

在动手改造前，我们需要先绘制出系统的"危险区域地图"。通过全局搜索SerializerFeature.WriteClassName和@type关键词，很快定位到三类典型场景：

1. 跨服务消息传递：消息体中携带@type标识具体实现类
2. 泛型容器序列化：List<BaseType>通过类型标记保留具体子类信息
3. 历史数据持久化：数据库JSON字段里存储着带类型标记的旧数据

提示：使用以下命令可以快速统计项目中@type的出现频率：

grep -r "@type" src/ | wc -l

我们构建了一个依赖关系矩阵来评估改造复杂度：

2. 渐进式改造策略设计

2.1 建立白名单安全网

直接移除所有@type就像高空拆弹，我们需要先布置安全网。利用Fastjson 1.2.68+的AutoTypeCheckHandler机制，为关键模块配置临时白名单：

public class WhitelistHandler implements AutoTypeCheckHandler { private static final Set<String> ALLOWED_TYPES = ImmutableSet.of( "com.xxx.Message", "com.xxx.Notification" ); @Override public Class<?> handler(String typeName, Class<?> expectClass, int features) { return ALLOWED_TYPES.contains(typeName) ? ParserConfig.getGlobalInstance().checkAutoType(typeName, null) : null; } }

注册处理器时需要注意线程安全问题：

// 在应用启动时一次性配置 ParserConfig.getGlobalInstance().addAutoTypeCheckHandler(new WhitelistHandler());

2.2 类型标记的替代方案

对于消息系统，我们采用显式类型字段替代@type：

public class MessageWrapper { private String messageType; // TEXT/IMAGE/VIDEO private String payload; public BaseMessage toMessage() { switch (messageType) { case "TEXT": return JSON.parseObject(payload, TextMessage.class); case "IMAGE": return JSON.parseObject(payload, ImageMessage.class); default: throw new IllegalArgumentException(); } } }

改造前后的数据对比：

3. 深度重构关键模块

3.1 消息处理引擎改造

原消息分发逻辑严重依赖运行时类型判断：

// 旧代码 BaseMessage msg = JSON.parseObject(json); if (msg instanceof OrderMessage) { processOrder((OrderMessage)msg); } else if (msg instanceof PaymentMessage) { processPayment((PaymentMessage)msg); }

重构为注册式处理器模式：

// 新代码 public interface MessageHandler<T extends BaseMessage> { String getMessageType(); void handle(T message); } @Getter @AllArgsConstructor public class OrderMessageHandler implements MessageHandler<OrderMessage> { private final String messageType = "ORDER"; @Override public void handle(OrderMessage message) { // 处理逻辑 } }

通过Spring的自动注册机制构建处理器映射：

@Configuration public class MessageConfig { @Bean public Map<String, MessageHandler<?>> handlers( List<MessageHandler<?>> handlerList) { return handlerList.stream() .collect(Collectors.toMap(MessageHandler::getMessageType, h -> h)); } }

3.2 数据迁移方案

对于已经存储在数据库中的历史数据，我们编写迁移脚本分批次处理：

-- 示例：PostgreSQL JSON字段更新 UPDATE message_store SET content = jsonb_build_object( 'messageType', 'TEXT', 'payload', content->'content' ) WHERE content->>'@type' LIKE '%TextMessage';

4. 保障重构质量的测试策略

4.1 契约测试保障

使用Pact作为契约测试工具，确保消息格式变更不会破坏上下游集成：

@Pact(provider = "MessageService", consumer = "OrderService") public RequestResponsePact createPact(PactDslWithProvider builder) { return builder .given("text message exists") .uponReceiving("request for message") .path("/messages/1") .method("GET") .willRespondWith() .status(200) .body(new PactDslJsonBody() .stringType("messageType", "TEXT") .stringType("payload.content", "hello")) .toPact(); }

4.2 反序列化测试矩阵

建立全面的反序列化测试用例：

@ParameterizedTest @CsvSource({ "TEXT, {\"content\":\"test\"}, TextMessage", "IMAGE, {\"url\":\"test.jpg\"}, ImageMessage" }) void shouldDeserializeByType(String type, String payload, Class<?> expectedClass) { String json = String.format("{\"messageType\":\"%s\",\"payload\":%s}", type, payload); BaseMessage message = JSON.parseObject(json, BaseMessage.class); assertThat(message).isInstanceOf(expectedClass); }

5. 性能优化与监控

改造完成后，我们在关键路径添加了监控点：

@Aspect @Component public class JsonMonitor { @Around("execution(* com..*.parse*(..))") public Object monitorParse(ProceedingJoinPoint pjp) throws Throwable { long start = System.nanoTime(); try { return pjp.proceed(); } finally { Metrics.timer("json.parse.time") .record(System.nanoTime() - start, TimeUnit.NANOSECONDS); } } }

性能对比数据显示：

在消息处理模块，我们意外发现移除动态类型判断后，方法内联优化使得吞吐量提升了30%。这个历时三周的重构项目最终不仅解决了安全问题，还意外获得了性能红利。