封装的核心是明确职责边界与行为约束，而非仅语法隔离；private字段+getter/setter不等于真正封装，需校验逻辑、防御性拷贝、不可变设计等保障内部状态可控。
封装不是为了“把代码藏起来”，而是为了明确谁该用什么、不该碰什么——只要接口不变，内部怎么改都不影响调用方。
为什么private字段 + public getter/setter 不等于封装
很多初学者以为加了private再配一对getX()/setX()就完成了封装，其实只是语法层面的隔离。真正的封装体现在行为约束上：
-
setAge(int age)如果直接赋值而不校验，那private只挡住了字段，没挡住错误数据 - 返回可变对象（如
ArrayList）时，若直接返回引用，外部仍能绕过setter修改内部状态 - getter 返回数组或集合时，应考虑用
Collections.unmodifiableList()或复制副本
final和不可变类在封装中的实际作用
封装的强度，很大程度取决于内部状态是否可控。final字段配合私有构造、无 setter，是构建不可变类的基础：
-
final修饰基本类型/引用，确保初始化后不被重赋值 - 但仅靠
final不够：若引用的是StringBuilder，外部仍可通过其方法修改内容 - 真正安全的不可变类，需同时满足：
final类、final字段、所有字段私有、构造器完成初始化、不提供修改内部状态的方法、返回对象副本而非引用
什么时候该用封装，什么时候反而该暴露？
封装不是越严越好。过度封装会增加维护成本，甚至阻碍合理扩展：
立即学习“Java免费学习笔记（深入）”；
-
工具类（如
StringUtils）通常全static方法，无需实例封装 - DTO/VO 类如果只做数据搬运，且确定不会加入业务逻辑，用
public字段反而更轻量（Lombok 的@Data本质也是生成访问器，不是封装逻辑） - 测试场景下，有时需要临时绕过封装（如用
ReflectionTestUtils设私有字段），但这属于调试手段，不能作为设计依据
最容易被忽略的一点：封装的价值不在定义时，而在演化中——当你要改一个private方法的实现，却不用动任何调用它的public方法签名，那一刻封装才真正起了作用。
