包访问权限是需主动设计的协作边界，依赖语义化包结构（如api/internal/spi）、严格物理归属、命名与文档规范，并警惕jpms缺失、测试同包及反射导致的编译期契约失效。

包访问权限（默认修饰符）在大型项目中不是随意留白的“省略”，而是有意识设计的协作边界。它真正起作用的前提，是包结构本身承载了明确的设计意图——包名即契约，包内即信任域。

按语义分层，用包名传递协作范围

不要只按技术角色（如 controller/service/dao）粗粒度划分，而要叠加业务语义。例如：

• com.example.order.api：只放 public 接口和 DTO，定义对外契约，不包含实现
• com.example.order.internal：存放 default 工具类、状态枚举、构建器、内部事件等，仅限本模块内高效协作
• com.example.order.spi：含 public 扩展接口 + default 回调钩子，供插件实现但不暴露底层细节

把“同包可见”当作编译期契约来维护

默认权限的威力在于编译失败能立刻暴露越界调用。要做到这点，需守住两个底线：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 同一语义模块的所有协作类必须物理归属同一个包——不能因“复用方便”把工具类扔进通用包（如 com.example.common），否则等于向全项目开放
• 避免多模块定义相同包名（如 module-a 和 module-b 都声明 package com.example.service），classpath 合并后会绕过包级隔离，导致默认成员意外可访问

配合命名与文档，让意图可读、可查、可传承

光靠包名还不够，团队协作需要显性提示：

• 对 default 类或方法加命名后缀，如 OrderValidatorInternal、AmountParserHelper
• Javadoc 明确标注 “For internal use within com.example.order only”，IDE 能识别并提示
• 在模块 README 或架构文档中说明该包的设计目的：“impl 包内类通过 default 成员自由组合，但禁止跨包直接 new 或调用”

警惕运行时环境对默认权限的削弱

默认权限是编译期机制，但在某些场景下会失效或退化：

• 未启用 JPMS（无 module-info.java）时，类加载器规则可能覆盖包级限制，尤其在 OSGi 或复杂 classpath 场景下
• 测试代码（如 src/test/java）若与主代码同包，会自动获得 default 访问权——这是便利，也是风险，需确保测试不依赖内部实现
• 反射仍可突破 default 限制，但应视为调试/框架行为，不用于常规业务逻辑

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南