ORM需清空并重建反射元数据缓存以应对MySQL表结构变更，包括类-表映射、主键字段、持久化字段列表、字段-列名双向映射及类型转换策略；清空时须用ConcurrentHashMap.clear()、丢弃Field引用、确保模块开放且避免递归；重建需容错处理缺失字段、类型不匹配等异常。
遇到 MySQL 表结构动态变更（如新增字段、删列、改类型）时，ORM 层若缓存了旧的元数据（比如字段名→列名映射、主键信息、类型转换规则），会导致查询失败、赋值错位或空指针异常。要让 ORM 框架“感知变化”，关键不是监听数据库 DDL，而是主动清空并重建反射获取的元数据缓存——这比实时监听更可控、更轻量。
识别哪些元数据需要清空
反射构建的 ORM 元数据通常缓存在静态 Map 或 ConcurrentMap 中，常见缓存项包括：
- 类 → 表名映射（来自 @Table 注解）
- 类 → 主键字段（@Id 字段及其位置）
- 类 → 所有持久化字段列表（含 @Column(name)、是否可为空、长度等）
- 字段名 ↔ 列名的双向映射关系（用于 ResultSet 列名匹配）
- 字段类型 ↔ JDBC 类型的转换策略（如 LocalDateTime → Timestamp）
清空缓存的反射操作要点
不能只清空 Map，还要确保后续反射调用能重新安全加载。需注意：
- 缓存容器本身要是线程安全的（推荐 ConcurrentHashMap），清空用 clear() 而非重新 new
- 若缓存中存了 Field 实例（为避免反复调用 getDeclaredFields()），清空时也要丢弃这些引用——Field 对象不随类加载器卸载而失效，但指向的字段可能已不存在，必须重建
- 清空后首次访问该类时，要重新执行 clazz.getDeclaredFields() 并调用 setAccessible(true)；Java 9+ 模块环境下，还需确认模块已通过 --add-opens 开放，否则 setAccessible 会静默失败
- 不要在清空过程中触发新实体的反射解析（避免递归或死锁），建议用独立线程或延迟初始化机制
触发清空的合理时机
完全自动监听 DDL 不现实，推荐人工+半自动结合：
立即学习“Java免费学习笔记（深入）”；
- 提供一个管理端点（如 Spring Boot Actuator 的 /actuator/orm-clear），运维在执行 ALTER TABLE 后手动触发
- 在 DAO 层捕获特定 SQL 异常（如 Unknown column、Column count doesn't match），记录日志并自动清空对应类的缓存
- 开发环境启用热刷新时，监听类文件变更（如使用 FileWatchService），检测到 Entity 类修改后清空其缓存（适合本地快速验证）
- 避免定期全量清空——开销大且无必要；只清关联变更表的实体类缓存即可
清空后如何安全重建
重建不是简单重跑反射逻辑，要注意容错：
- 加 try-catch 包裹反射过程，对缺失字段、类型不匹配、注解缺失等情况做降级处理（如跳过该字段、记录警告日志）
- 检查实体类是否仍有无参构造器——表结构变更是常见，但删掉无参构造器会导致 newInstance() 失败，需提前校验
- 重建字段映射时，若发现 @Column(name="xxx") 指向的列在 ResultSetMetaData 中不存在，应跳过该字段，而非抛异常中断整个对象填充
- 时间类型字段（如 LocalDateTime）若数据库列类型变成 VARCHAR，应记录类型不匹配警告，但允许设为 null，不阻断流程
