职场后端工作一年的小白~就当记录一点点心得吧

1. 前言：迷失与觉醒

工作一年多，发现自己越来越习惯于业务开发，每天就是CRUD（增删改查）。刚毕业时那种对技术的热忱，似乎在日复一日的业务代码中慢慢消磨掉了。最近翻开BOSS直聘，才发现自己和市场的要求渐行渐远。
不想就这样平庸下去，不想一直做“CRUD仔”，我也有大厂梦，也渴望年薪百万。
所以，从今天起，我决定珍惜每一寸时间，每天坚持学习，写下自己的技术成长打卡，从面试题到自学项目，一步步捡回那些被遗忘的基础和热情。

2. 技术回顾：Java中的序列化与反序列化

2.1 什么是序列化和反序列化？

说实话，工作了一年，对“序列化”这个词还停留在“DTO实现一下Serializable接口，然后加个serialVersionUID”的印象。
但实际它的作用远不止如此：

• 序列化：把Java对象转换为字节流（byte stream），以便进行网络传输、存储到文件或数据库、缓存等操作。
• 反序列化：将字节流还原成Java对象。

2.2 Serializable接口的作用

Serializable是Java序列化机制的核心接口。实现了它的对象才能被序列化和反序列化。 常见场景包括：

• 网络传输对象
• 持久化对象到文件/数据库
• 缓存（如Redis）存储对象
• 消息队列传递对象
• 分布式服务间数据传递

2.3 serialVersionUID到底有什么用？

我曾经以为private static final long serialVersionUID = 1L;只是个规范，后来才明白它的真正用途：

• serialVersionUID是用来标识类版本的唯一ID。
• 如果类结构发生变化（比如字段增加、删除），没有指定serialVersionUID，JVM会自动生成一个，导致不同版本间ID不一致。
• 如果用不同版本的类去反序列化同一个对象，就会抛出InvalidClassException异常。

3. 踩坑实录：一次生产事故引发的思考

真实场景如下：

• 生产环境有两台服务器A/B
  • A：老版本（1.0）
  • B：新版本（2.0）
• A序列化对象并写入缓存（如Redis），B读取并尝试反序列化
• 因为A/B的类结构不同，自动生成的serialVersionUID不同
• B反序列化时报错InvalidClassException

java

// A服务器写入缓存 MarketingTicketV1 ticket = new MarketingTicketV1("001", "优惠券", 100); redis.set("ticket:001", serialize(ticket)); // serialVersionUID: 12345 // B服务器读取缓存 MarketingTicketV2 ticket = (MarketingTicketV2) deserialize(redis.get("ticket:001")); // serialVersionUID: 67890，报错 InvalidClassException

原因分析： 如果没有手动指定serialVersionUID，不同版本的类自动生成的ID不一致，导致无法兼容升级。

4. 总结与提升

4.1 为什么要手动指定serialVersionUID？

• 保证版本兼容性，支持平滑升级
• 避免序列化数据因类结构微调而无法读取
• 保证分布式、缓存、消息队列等场景下服务稳定运行

4.2 Serializable在项目中的实际价值

• 支持ORM框架（如MyBatis-Plus）持久化映射
• 支持Spring Boot HTTP请求/响应对象传递
• 支持Redis等缓存系统对象存储
• 支持消息队列数据传递
• 支持分布式系统服务间通信

4.3 我的收获

每一个“习以为常”的小细节，其实都藏着大智慧。技术成长不是一蹴而就，而是靠每天一点一滴积累。