封装通过private限制直接访问、getter/setter控制修改入口来保障数据安全；private字段切断外部直连，setter中可校验年龄非负等约束。
Java 中封装通过“限制直接访问 + 控制修改入口”的方式保护对象内部数据安全，核心不是不让改，而是让每一次修改都经过校验和约束。
用 private 锁住字段，切断外部直连
把成员变量声明为 private，是封装的第一步。这相当于给数据加了一道门锁——外部代码连门把手都摸不到，自然无法绕过逻辑直接赋值。
- 即使字段名被猜中，编译器也会报错，运行时也无法反射绕过（Java 24 起默认禁止非法反射访问）
- 常见错误写法：
public int age;—— 这等于把数据库账号密码贴在服务器外壳上 - 正确姿势：
private String idCardNo;，哪怕只是存个字符串，敏感信息也绝不裸露
用 getter/setter 建立可控通道
公开的 getter 和 setter 不是摆设，它们是唯一被允许进出的安检口。所有读写操作必须排队接受检查，比如年龄不能为负、余额不能透支、身份证号必须符合格式。
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
setAge(int age)里可以 throw 异常或静默修正：if (age -
getBalance()可以返回副本（如new BigDecimal(balance)），防外部篡改原始值 - 需要只读？只提供 getter；需要只写？只提供 setter；需要延迟计算？getter 里加逻辑
在关键场景中堵死数据污染路径
封装的价值在业务边界处最明显：银行账户、库存数量、用户权限等一旦被随意修改，系统就可能出错甚至崩溃。
- 例如
BankAccount类中，balance是 private，withdraw()方法内会检查余额是否充足，而不是让调用方自己判断再直接减 - 再如电梯控制系统，
currentFloor是 private，外部只能调用goTo(int target)，内部自动处理开门、关门、超重拦截等逻辑 - 没有封装，等于把油门、刹车、方向盘全交给乘客——能开，但不安全
配合不可变性与线程安全进一步加固
封装本身不保证线程安全，但它是基础。配合 final、不可变对象（Immutable）、私有锁等手段，才能应对并发场景。
- 字段用
private final声明，构造时初始化，之后彻底不可变（如String、LocalDateTime） - 若需修改状态，用私有锁（
private final Object lock = new Object();）保护临界区，避免客户代码误持锁 - 集合类也需封装：不返回
private List<item> items;</item>的原始引用，而返回Collections.unmodifiableList(items)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
