必须用 private 修饰类的内部状态字段，以防止外部绕过业务逻辑篡改数据；非静态字段默认应为 private，构造器、getter/setter 和工具方法按需暴露，但字段本身不例外。
什么时候必须用 private？
类的内部状态（比如字段）只要不被外部直接读写，就该默认设为 private。这不是为了“藏起来”，而是防止调用方绕过业务逻辑篡改数据。比如一个 BankAccount 类里的 balance 字段，如果公开成 public，别人就能直接写 account.balance = -1000000，跳过所有校验。
- 所有非静态字段优先声明为
private - 构造器、getter/setter、工具方法按需暴露，但字段本身不例外
- 子类继承时，
private成员不可见——这是设计意图，不是限制
public 方法该暴露哪些？
一个方法是否该是 public，取决于它是否构成该类对外承诺的契约。比如 String.trim() 是 public，因为它是 String 类明确提供给所有调用方使用的功能；而 ArrayList 内部的 grow() 就是 private，它只服务自身扩容逻辑，换实现就可能消失。
- 仅当该方法被其他类（尤其是不同包下的类）合理依赖时，才设为
public - 避免为“以后可能用到”提前暴露
public方法 - 接口方法必须是
public（Java 9+ 允许private接口方法，但那是另一回事）
别碰 protected 和包级访问的模糊地带
很多开发者把 protected 当作“比 private 松一点”的快捷方式，结果导致子类意外依赖父类实现细节。更常见的是误用包级访问（即不写修饰符），以为“同包内安全”，实际却让测试类、工具类、甚至未来新增的同包子类轻易穿透封装边界。
-
protected应仅用于明确支持继承扩展的钩子方法（如Swing组件的paintComponent()） - 包级访问等价于“全包信任”，一旦包变大或职责混杂，维护成本陡增
- 宁可加一层
public的委托方法，也不开放protected字段
IDE 和 Lombok 会掩盖封装问题
IntelliJ 自动生成 getter/setter 时，默认生成 public 方法，但不会提醒你：这个字段真需要被外部修改吗？Lombok 的 @Data 更危险——它一键生成所有 public getter/setter，等于把所有字段都“合法裸奔”。曾经有项目用 @Data 修饰 DTO，结果前端传个负数 ID，后端毫无感知地存进数据库。
立即学习“Java免费学习笔记（深入）”；
public class Order {
private Long id; // ✅ 应保持 private
private BigDecimal total; // ✅ 同上
// ❌ @Data 会自动生成 public void setTotal(BigDecimal t)，但 total 应由业务方法计算得出
}
- 用 Lombok 时，优先选
@Getter+ 手动写业务 setter，或用@Accessors(fluent = true)配合私有化 - IDE 生成 getter 前，先问一句：“谁真的需要读它？有没有更安全的只读视图？”
- 单元测试应尽量走
public接口，而不是反射访问private字段——后者是在测试实现，不是测试行为
