封装的核心是控制变更影响范围而非盲目私有化字段。应优先使用private final+构造器注入实现不可变性，校验逻辑前置到构造器；集合返回需不可变包装；DTO、Entity、领域对象须严格分离封装粒度。
封装不是越深越好，而是让调用方看不到不该看的
Java 的封装核心目标不是“把所有字段都 private + getter/setter”，而是控制变更影响范围。过度封装反而会增加维护成本、阻碍测试、拖慢迭代——比如给每个 String 字段配一个 setXXX() 和 getXXX()，但实际业务中这个字段从不被外部修改，也不参与任何逻辑判断，那它只是徒增噪声。
什么时候该用 private final + 构造器注入，而不是 setter？
当对象创建后状态不应再改变时，private final 是更安全的选择。这直接规避了并发修改、意外重置、空指针等常见问题。尤其在 Spring 管理的 Bean、DTO、VO、领域模型中，应优先考虑不可变设计。
-
setter仅在明确需要运行时动态更新状态时才引入（如配置刷新、缓存控制） - 若字段需校验（如邮箱格式、非空），应在构造器中完成，而非留到
setXXX()里延迟抛异常 - 避免为
final字段提供setXXX()—— 编译器会报错，但团队里有人可能绕过它用反射强行修改，这种“破窗”行为比没封装更危险
public class User {
private final String email;
private final int age;
public User(String email, int age) {
if (email == null || !email.contains("@")) {
throw new IllegalArgumentException("Invalid email");
}
if (age < 0 || age > 150) {
throw new IllegalArgumentException("Invalid age");
}
this.email = email;
this.age = age;
}
// no setters
public String getEmail() { return email; }
public int getAge() { return age; }
}
getter/setter 不等于封装，暴露内部结构才是真问题
常见反模式：返回可变集合引用、暴露内部 List 或 Map 实例。调用方拿到后直接 add() 或 clear()，就破坏了对象一致性。
- 返回集合时用
Collections.unmodifiableList()或ImmutableList.copyOf()（Guava） - 避免返回
private List<Order> orders;的原始引用，改用public List<Order> getOrders() { return Collections.unmodifiableList(orders); } - 如果调用方确实需要修改集合，提供明确语义的方法，如
addOrder(Order order)、removeOrderById(String id)，而不是开放整个容器
DTO 与 Entity 的封装粒度必须分离
很多人把 JPA @Entity 类直接当 API 返回值用，结果数据库字段（如 created_at、is_deleted）全暴露给前端；或者反过来，在 DTO 里塞一堆业务逻辑方法，混淆了数据载体和行为载体的边界。
立即学习“Java免费学习笔记（深入）”；
-
@Entity类只负责映射数据库，字段可protected或包私有，靠 JPA 反射访问，不对外暴露 getter/setter - DTO 应是纯数据容器，字段
public final或带private+ Lombok@Data（注意@Data默认生成setter，慎用） - 领域对象（Domain Object）才该封装行为，比如
user.deactivate()内部同时设置status = INACTIVE和记录deactivatedAt = now()，而不是让调用方手动 set 两个字段
真正难的不是加 private，而是判断哪个字段该藏、哪个行为该收、哪层该透出——这取决于上下文，而不是某条封装规则。
