notserializableexception 是运行时异常，需通过主动扫描不可序列化字段、标记 transient 并重写 readobject()、编写序列化回归测试及构建阶段静态检查来预防。
NotSerializableException 是受检异常（checked exception），但实际开发中它不会在编译期报错，只在运行时序列化/反序列化操作中触发。预防和测试的关键在于主动暴露问题、提前校验结构，而非依赖编译器拦截。
提前识别不可序列化字段
Java 序列化机制不递归检查字段类型，仅在 writeObject() 或 readObject() 执行时才抛出异常。因此必须人工或工具辅助排查：
- 用 IDE 的“Find Usages”配合手动扫描：重点查日志对象（如 SLF4J 的
Logger）、线程相关类（Thread、ThreadLocal）、I/O 类（FileInputStream、Socket）、反射类（Class、Method）等——它们都未实现Serializable - 检查内部类是否为非静态：非静态内部类隐含持有外部类实例引用（
this$0），若外部类没实现Serializable，就会连带失败 - 对第三方库字段，查阅其 Javadoc 或源码确认是否实现了
Serializable；不确定时默认按不可序列化处理
用 transient + 自定义 readObject() 控制序列化行为
加 transient 能跳过字段序列化，但只是“止血”，不是“治愈”。必须确保字段在反序列化后能安全重建：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 所有
transient字段应在private void readObject(ObjectInputStream in)中重新初始化，例如日志器：this.logger = LoggerFactory.getLogger(getClass()); - 避免对
final字段使用transient：反序列化不调用构造器，final字段无法赋值，结果必为null或默认值 - 资源型字段（如连接池引用、回调函数、缓存容器）适合用
transient标记，并在readObject()中延迟重建
编写可执行的序列化回归测试
光靠代码审查不够，必须有自动化测试验证序列化路径是否真正畅通：
- 写一个单元测试：创建目标对象 → 写入
ByteArrayOutputStream→ 读回新实例 → 断言字段值与预期一致（注意transient字段应被重置或忽略） - 每次修改类结构（尤其新增字段）后，强制运行该测试；若引入新依赖，也需同步更新测试用例
- 对使用缓存（如 Ehcache）或分布式框架（如 Flink、Spark）的场景，额外模拟真实环境：把对象放入缓存再取出，或提交到远程执行上下文，观察是否抛出
NotSerializableException
构建阶段加入静态检查（可选但推荐）
借助工具在 CI 流程中提前拦截风险：
- 使用
serialver工具生成并核对serialVersionUID，避免因版本不一致导致反序列化失败（虽不直接防NotSerializableException，但属序列化健康检查一环） - 集成 Checkstyle 或自定义 SonarQube 规则，扫描类中是否存在未标记
transient的不可序列化字段（需维护常见不可序列化类型白名单） - 在构建脚本中运行轻量级序列化探针：反射遍历所有字段类型，对已知不可序列化类（如
java.lang.Thread、org.slf4j.Logger）发出警告
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
