核心业务封装需在类、成员、包三层协同划界：入口类用public且独占文件，内部类用默认修饰符隔离；字段方法按职责设权限，敏感数据private、包内复用默认、子类扩展protected；包结构固化边界，配合默认权限实现编译期防火墙；极敏感逻辑用private静态内部类收紧。
核心业务类的封装不是靠堆砌 private，而是用权限修饰符在“类—成员—包”三层上协同划界：让不该进来的进不来，该协作的协作好，该暴露的接口干净可控。
顶层类本身就得设好门禁
业务主类（比如 OrderService、PaymentProcessor）是否允许跨包使用，直接决定整个模块的边界：
- 对外提供稳定能力的入口类，才用
public；必须独占一个文件，且类名与文件名严格一致 - 纯内部协调用的类（如状态机、校验器、组装器），直接用默认修饰符（不写任何关键字）——其他包连 import 都报错，根本找不到它
- 若整个业务模块不希望被外部依赖，连入口类都设为默认，再配合包名隔离，相当于给模块加了一道编译期防火墙
成员字段和方法按职责定权限
字段和方法的修饰符要匹配其实际用途，而不是统一设成 public 或 private：
- 敏感数据（如余额、密钥、状态码）一律
private，只通过带校验逻辑的 public 方法操作 - 包内复用的工具方法、构建逻辑、解析器等，用默认权限——同包服务可调，Web 层或 RPC 接口层无法直连
- 需要被子类扩展但不希望外部随意调用的，用
protected；注意不同包子类只能通过this访问，不能操作父类实例的 protected 成员
用包结构固化模块边界
包不是文件夹别名，是代码的行政区。把同一业务域的类放进一个包（如 com.example.order），再配合默认权限，就能自然形成高内聚单元：
立即学习“Java免费学习笔记（深入）”；
-
OrderValidator的校验逻辑设为默认，OrderService可调，但UserController（在com.example.user包）连编译都过不去 - DTO 构造器、Builder 的中间状态字段设为默认，强制走
build()入口，避免绕过合法性检查 - 模块升级时，一旦有跨包调用，编译失败立刻暴露依赖问题，而不是等到运行时报空指针或状态异常
必要时用内部类收紧关键路径
对极敏感的核心逻辑（如密钥管理、事务补偿），可进一步收口：
- 把操作封装进
private static class，外部连类名都不可见，反射也受模块系统限制 - 外围类持有一个
private字段引用该内部类，只暴露带规则的 public 方法（例如encrypt(String)内部做密钥派生+加解密） - 临时高危操作（如权限校验、幂等判断）用局部内部类或匿名类，生命周期锁死在方法内，无继承、无复用、无泄露风险
