Java访问修饰符仅有public、protected、default、private四种，其核心价值在于通过可检查、可嵌入研发流程的工程化规则，实现分层契约（如Controller方法public、Domain字段private）、禁用模糊地带（限制protected和包级使用）、联动模块依赖（exports与public同步）、并借ArchUnit/Checkstyle等工具自动化兜底。
Java 访问修饰符本身只有 public、protected、default（包级私有）、private 四种，但企业级规范落地的关键不在于“记住语法”，而在于用一套可检查、可传承、可嵌入研发流程的规则，把“该暴露的暴露、该隐藏的隐藏”变成团队共识和工程实践。
明确分层契约：按架构层级约定可见性边界
企业项目通常有清晰分层（如 controller → service → repository → domain），每层对外只暴露最小必要接口，修饰符是实现该原则的第一道防线：
-
Controller 层：所有 handler 方法必须
public（Spring MVC 要求），但整个类建议加@RestController注解而非手动设public类——靠框架约束比修饰符更可靠；内部辅助方法一律private，禁止protected或包级。 -
Service 接口：定义为
public interface，实现类用public class，但实现类中非接口方法（如模板逻辑、校验工具）必须private；跨模块调用的服务接口，禁止在实现类中暴露protected方法供子类重写——用策略模式或组合替代继承。 -
Domain 实体：字段全部
private，getter/setter 按需提供（如 DTO 可全开，Entity 仅开放读/写必要字段）；构造器优先用private+ 静态工厂方法（如of()、from()），避免外部直接 new。
禁用模糊地带：限制 protected 和包级修饰符的使用场景
protected 和默认包级在企业代码中容易引发耦合和误用，需明文禁止或强约束：
- 禁止在非模板类、非框架扩展点中使用
protected字段或方法。若真需子类扩展，必须配套 Javadoc 说明“此方法专供继承扩展”，并搭配@Override注解强制子类显式覆盖。 - 包级（default）修饰符仅允许用于：同一业务包内高度内聚的工具类（如
xxx.internal子包）、测试辅助类（TestUtils）、或 Spring@Configuration中的@Bean方法（因 Spring 容器可访问包级方法）。 - 静态代码扫描（如 SonarQube）配置规则：对
protected成员触发告警，要求提交时附带“继承设计说明”；对跨包访问包级成员直接报阻断错误。
与依赖管理联动：修饰符是模块化落地的“最后一厘米”
微服务或模块化单体中，访问修饰符要和模块依赖方向保持一致：
立即学习“Java免费学习笔记（深入）”；
- 如果 A 模块
requires B（Java 9+ module-info），则 B 模块中被 A 调用的类/接口必须是public，且所在包必须在exports列表中——修饰符有效性和模块声明必须同步维护。 - Maven 多模块下，
api模块只放public interface和 DTO；impl模块中的实现类用public，但内部协作类（如xxx.support）统一设为package-private，并通过 Maventest-jar机制向test模块有限开放。 - 禁止在
impl模块中出现public工具类被api模块间接引用——这类类应下沉到独立的common模块，并严格分类（core/util/extension）。
自动化兜底：把修饰符规则编入 CI 流程
靠人工 Review 无法长期保障，需技术手段固化：
- 使用
ArchUnit编写断言，例如：noClasses().that().resideInAPackage("..service..")<br> .should().accessClassesThat().resideInAPackage("..controller..")
配合修饰符检查（如 “service 类不得有 public 字段”）。 - Checkstyle 配置
VisibilityModifier规则，强制字段私有化、禁止 public static 非 final 字段、限制 protected 使用范围，并集成进 pre-commit hook。 - 在 IDE（IntelliJ）中导入统一编码规范文件，使
private字段未加 private 修饰符时标黄提示；新类创建时自动补全private修饰符（通过 Live Template）。
