必须用 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 松一点”的快捷方式，结果导致子类意外依赖父类实现细节。更常见的是误用包级访问（即不写修饰符），以为“同包内安全”，实际却让测试类、工具类、甚至未来新增的同包子类轻易穿透封装边界。
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
-
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字段——后者是在测试实现，不是测试行为
