本文深入解析 jpa 的 `@access` 注解如何在单个字段上覆盖默认访问策略，通过 `accesstype.field` 与 `accesstype.property` 混用实现细粒度控制，并提供可验证的单元测试证明其行为差异。
在 JPA 规范中，实体的默认访问类型（Access Type）由 @Id 注解的位置决定：若 @Id 标注在字段上（如 private Long ID;），则整个实体默认采用 AccessType.FIELD —— 即 JPA 直接通过反射读写字段值，完全绕过 getter/setter 方法；反之，若 @Id 标注在 getter 上，则默认为 AccessType.PROPERTY，JPA 会通过属性访问器（getter/setter）操作数据。
但 @Access 注解的强大之处在于它支持字段级覆盖。你可以在任意非 @Id 字段上显式声明 @Access(AccessType.PROPERTY)，强制 JPA 对该字段改用 getter/setter 访问，即使其他字段仍走字段直读模式。这正是你示例中 lastName 字段的行为基础：
@Access(value = AccessType.PROPERTY) private String lastName; // ← 此字段将通过 getLastName()/setLastName() 访问
而 firstName 未加 @Access，且实体整体为 FIELD 模式，因此 JPA 不会调用 getFirstName() 或 setFirstName() —— 它直接读写 firstName 字段本身。这也是你日志未触发的关键原因。
✅ 验证逻辑如下：
- firstName：设值时 student.setFirstName("John") 是普通 Java 调用，但 JPA 持久化时跳过该 setter，直接写入字段 "John"；
- lastName：因 @Access(PROPERTY)，JPA 在持久化时主动调用 setLastName("Doe")，故实际存入数据库的是 "LastName: Doe"；查询时也通过 getlastName()（注意方法名拼写错误，应为 getLastName()）读取。
⚠️ 注意事项：方法名必须严格匹配 JavaBean 规范：setLastName(String) / getLastName()，你代码中 getlastName() 是非法 getter（首字母未大写），会导致 JPA 忽略该属性或抛出异常；测试前务必修正 getter/setter 命名，否则 @Access(PROPERTY) 将失效；@Access 仅影响 JPA 的持久化/加载过程，不影响业务代码对 setter 的手动调用。
以下是可运行的完整测试用例（已修正命名并增强断言）：
@Test
public void testAccessAnnotationBehavior() {
EntityManager em = entityManagerFactory.createEntityManager();
em.getTransaction().begin();
Student student = new Student();
student.setFirstName("John"); // 手动调用，但 JPA 不使用它
student.setLastName("Doe"); // JPA 会调用此 setter（因 @Access(PROPERTY)）
em.persist(student);
em.flush(); // 确保 SQL 执行并生成 ID
Long id = student.getID();
em.getTransaction().commit();
em.clear();
// 重新加载实体
Student loaded = em.find(Student.class, id);
// 断言：firstName 未被 setter 加工 → 仍为 "John"
assertEquals("John", loaded.getFirstName());
// 断言：lastName 被 setLastName() 加工 → 存储为 "LastName: Doe"
assertEquals("LastName: Doe", loaded.getLastName());
}? 总结：@Access 是实现混合访问策略的核心工具，适用于需要在字段级注入逻辑（如自动格式化、审计赋值、加密封装）的场景。但务必确保对应 getter/setter 符合规范，且理解其作用域仅限于 JPA 生命周期 —— 它不改变 Java 对象的常规行为，只改变 ORM 映射时的数据通道。
