java实体类封装需按业务语义建模、字段私有化、setter校验、getter返回不可变视图、区分用途模型、注解仅作映射桥梁；命名用驼峰与领域语言，布尔字段统一isxxx()，禁用@data于核心实体。
Java 实体类中的封装不是把数据库字段名原样搬进 Java 类，而是按业务语义建模、用访问控制约束行为、靠方法暴露意图。核心是让字段“可读可控”，而不是“可见可改”。
字段命名要语义化，不照搬数据库
数据库字段常为下划线风格（user_name、is_del、create_time），但 Java 实体类应使用领域语言和驼峰规范：
- 类名用业务实体名：如 User（不用 UserInfo 或 TUser）
- 属性名去前缀、重表达：name（非 userName）、isDeleted（非 isDel）、createdAt（非 createTime）
- 布尔字段统一用 isXxx() 命名 getter，便于 Jackson、MyBatis 等框架自动识别
所有字段必须 private，getter/setter 是唯一入口
public 字段或裸 setter 会绕过校验逻辑，导致非法状态。每个 set 方法都应承担基础守门职责：
- setEmail(String email) 中检查 null 和格式，非法则抛 IllegalArgumentException
- setPassword(String raw) 内部调用加密逻辑，原始密码不落地
- setStatus(int status) 应废弃，改用 activate()、deactivate() 等具名方法
- 返回集合的 getter（如 getRoles()）须包装为不可修改视图：Collections.unmodifiableList(roles)
区分模型用途，避免一个类承载全部字段
数据库表常含审计字段（create_time、update_by）、技术字段（version、deleted_flag）或冗余字段（total_count），但业务场景只需关注当前上下文需要的数据：
- 持久层用 UserEntity：含全部列，配 @Id、@Column、@Transient 等 ORM 注解
- 查询列表用 UserSummary：仅 id、name、avatar，轻量高效
- 编辑表单用 UserEditable：含 name、email、phone，不含 createTime 等只读字段
- 转换靠静态工厂方法：UserEditable.from(userEntity)，而非逐个 setXXX
注解只做映射桥梁，不定义模型契约
@Entity、@Table、@Column 等属于持久层配置，不应影响业务语义设计：
- 字段是否加 @Transient，取决于是否需持久化，而非“要不要在类里出现”
- 不要因为数据库有 deleted_flag 就在 User 类里硬塞一个 deletedFlag 属性——应命名为 isDeleted 并封装删除逻辑
- Lombok 的 @Data 可省代码，但默认生成的 setter 不校验、getter 返回原始引用，慎用于核心实体类
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
