企业级Java项目中访问修饰符是架构约束契约，核心目标为最小暴露原则、明确职责边界与可维护性保障；private为默认起点，protected仅用于文档化继承扩展点，public严格限定于契约层并配套管理，package-private支撑模块内协作与测试覆盖。
企业级 Java 项目中，访问修饰符不是语法自由选择项，而是架构约束和团队协作的契约。统一使用的核心目标是：最小暴露原则 + 明确职责边界 + 可维护性保障。不为“写得对”，而为“看得懂、改得稳、扩得清”。
private 是默认起点，非必要不升级
类内部成员（字段、方法、内部类）一律优先用 private。即使当前子类未出现、外部无调用，也不提前开放 protected 或 public。升级修饰符必须有明确动因：
- 被 Spring 管理的 Bean 方法（如 @PostConstruct 标注）需保持 private，框架通过反射调用，不构成暴露理由
- DTO/VO 字段必须 private，配合 Lombok 的 @Data 或显式 getter/setter，禁止 public 字段
- 工具类静态方法若仅被同包内调用，仍应设为 private，通过 package-private（即不写修饰符）+ 单元测试覆盖来验证复用性
protected 仅用于明确设计的继承扩展点
企业项目中，protected 不代表“可能被子类用”，而是“本类主动预留的、文档化支持的扩展钩子”。常见合规场景：
- 模板方法模式中，定义 abstract 或 protected 模板方法（如 doProcess()），并在 Javadoc 中标注 “Subclasses may override…”
- Spring Boot Auto-configuration 类中，为方便用户定制 Bean，将配置类的某些创建方法设为 protected，同时提供 public 的 builder 静态工厂
- 禁止在 service/entity 层随意用 protected 字段——这会破坏封装，导致子类误改状态，应改用策略接口或回调函数注入
public 严格限定在契约层，且需配套契约管理
public 仅出现在三层明确边界上，且每个 public 成员必须有可追溯的契约依据：
- Controller 层：@RestController 中的方法必须 public，但需配合 @Api 注解（Swagger）或 OpenAPI 规范描述输入/输出
- Facade/Service 接口：定义 public interface（如 OrderService），实现类用 package-private 或 final class，避免直接 new 实现类
- SDK 或公共组件：public 类/方法必须带 @since 版本号、@deprecated 标记及迁移路径，变更需走语义化版本（SemVer）评审
package-private（默认）是模块内协作的隐性契约
不写任何修饰符的成员，在企业多模块项目中承担关键角色：
- 同一业务模块（Maven module）内，service、repository、converter 等包间协作优先用 package-private，体现“模块自治”设计思想
- 测试包（src/test/java）可直接访问同名主包下的 package-private 成员，无需反射或 Testable，这是鼓励单元测试覆盖的设计支持
- 禁止跨模块（不同 artifactId）依赖 package-private 成员——构建时会失败，这种编译强制力比文档更可靠
规范落地靠工具，不靠自觉：在 Checkstyle 或 SonarQube 中配置规则，例如禁止 public 字段、限制 protected 使用频次、扫描未被测试覆盖的 public 方法。每次 PR 合并前自动拦截违规代码，比编码规范文档管用十倍。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
