java领域实体类应以不变性为默认原则：字段private final、用包装类表达缺失语义、构造时校验、equals/hashcode仅基于业务主键、getter返回不可变视图或副本，必要时用record简化。
Java 中编写健壮的领域实体类，核心不是堆砌技巧，而是理清职责边界：它要准确表达业务概念、保障数据一致性、避免被意外篡改，同时与 JVM 的类型系统（Object 与包装类）协同工作，而非对抗它。
用 final + private + 不可变字段守住底线
实体的本质是“有状态的业务概念”，但状态变更必须受控。不要暴露可变字段，也不要提供无约束的 setter。
- 所有字段声明为 private final，强制在构造时完成初始化
- 避免使用基本类型（如
int），统一用包装类（如Integer），以便表达“缺失”语义（null）——这在数据库映射、API 空值处理中至关重要 - 构造方法只接受必要参数，对关键字段做非空/范围校验（例如
Objects.requireNonNull(name)或id > 0） - 不提供无参构造器（除非 JPA 等框架强制要求，此时应加
@SuppressWarnings("unused")并明确注释用途）
重写 equals() 和 hashCode()：只基于业务主键，不碰包装类陷阱
包装类本身已正确实现 equals 和 hashCode，但你必须确保逻辑聚焦于业务身份，而非所有字段。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 仅用不可变的、能唯一标识该实体的字段参与比较（通常是 ID，或组合主键字段）
- 对包装类字段直接调用
Objects.equals(a, b)——它天然处理null，无需手动判空 - 避免在
hashCode中混入可能为null的非主键字段，否则哈希码会随状态变化而漂移（违反契约） - IDE 自动生成后务必检查：是否包含不该参与比较的字段？是否用了 == 而非 equals？
谨慎暴露 getter，绝不暴露 setter 或原始引用
getter 不是“安全出口”，而是契约的一部分。返回值必须保证调用方无法反向污染实体内部状态。
- 对于基本包装类（
Integer,LocalDateTime等不可变类型），直接返回即可 - 对于集合字段（如
List<orderitem></orderitem>），返回Collections.unmodifiableList(items)，而非原始引用 - 对于可变对象（如自定义的
Address类），若其本身可变，getter 应返回防御性副本（new Address(this.address)） - 避免为每个字段都写 getter —— 只暴露业务真正需要读取的属性
用 record（Java 14+）简化不可变实体，但保留扩展余地
若实体纯粹用于承载数据、无复杂行为、且确定长期不可变，record 是极佳选择：自动实现 equals/hashCode/toString，语法简洁，语义清晰。
- 声明为
public record User(Long id, String name, Integer age) { ... } - 可在 record 内定义私有辅助方法、静态工厂方法，或带校验逻辑的构造器（通过
this(...)委托） - 不适用于需继承、需频繁修改字段、或内部含复杂生命周期管理的场景 —— 此时仍用传统类更稳妥
- 注意：record 的字段隐式为
final且公开，若需封装逻辑（如计算属性），传统类更灵活
领域实体不是数据容器的别名，它是业务规则的第一道防线。用好 Object 的契约、尊重包装类的设计意图、把不变性当作默认选项——这样写出的类，自然远离空指针、状态错乱和并发陷阱。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
