Java反射+注解字段映射需满足：模块化下用--add-opens、注解@Retention(RUNTIME)、@Target覆盖类与字段、禁用字符串拼接SQL、实体类必须有无参构造器。
Java 反射 + 注解做字段映射时，Field.setAccessible(true) 不是万能钥匙
反射绕过访问控制确实能读写 private 字段，但实际映射中常因忽略 JVM 安全策略或模块系统（Java 9+）直接抛 IllegalAccessException 或静默失败。尤其在 Spring Boot 3+（基于 Java 17+ 模块化）里，未显式开放包会导致 setAccessible(true) 失效。
- 必须配合
Module.addOpens()（运行时）或--add-opensJVM 参数（启动时），例如：--add-opens java.base/java.lang=ALL-UNNAMED - 优先用
Field.get(obj)/Field.set(obj, value)替代 setter/getter 调用，避免因方法不存在或签名不匹配引发NoSuchMethodException - 缓存
Field实例并复用，反复调用Class.getDeclaredFields()有明显性能开销
@Table 和 @Column 注解必须声明 RetentionPolicy.RUNTIME
如果注解保留策略设为 SOURCE 或默认的 CLASS，运行时反射根本拿不到这些信息——框架一启动就“看不见”表名和列名，所有映射逻辑直接失效。
-
@Retention(RetentionPolicy.RUNTIME)是硬性前提，缺它整个注解体系形同虚设 -
@Target({ElementType.TYPE, ElementType.FIELD})要覆盖类和字段两级，否则无法同时绑定表名与字段映射 - 别在注解里放复杂逻辑（比如动态生成列名），反射阶段不执行方法体，只读取字面值
生成 SQL 时，PreparedStatement 的参数占位符不能靠字符串拼接
手动拼 SQL 字符串再 replace 占位符（如 "WHERE id = ?".replace("?", "123")）看似简单，实则埋雷：SQL 注入、类型丢失、NULL 处理错乱、数据库关键字转义缺失。
- 必须用
PreparedStatement的setXxx(index, value)系列方法，让 JDBC 驱动负责类型适配和转义 - 字段顺序要严格对应
getDeclaredFields()的返回顺序（或按注解order属性排序），否则参数错位 - 对
null值必须显式调用setNull(index, Types.INTEGER)等，不能传null给setObject
实体类无参构造器不是可选，而是反射实例化的刚性依赖
框架底层靠 Class.getDeclaredConstructor().newInstance() 创建空对象，一旦实体类只定义了带参构造器，就会抛 NoSuchMethodException，且这个异常容易被泛化成“映射失败”，排查困难。
- 即使你用 Lombok 的
@Data，也得显式加@NoArgsConstructor（尤其当存在@AllArgsConstructor时） - 构造器私有不影响反射调用，但必须存在；若需初始化某些 final 字段，可在构造器里赋默认值，而非依赖 setter
- 避免在无参构造器里做耗时操作（如连接数据库），它会在每次查询结果映射时被调用
真正麻烦的从来不是怎么把字段名变成列名，而是 JVM 模块限制、注解生命周期、SQL 参数绑定时机、以及那个你以为“肯定有”的无参构造器——它们散落在不同层面，但只要漏掉一个，映射就停在第一行日志里。
