包访问权限在微服务模块划分中不是辅助手段，而是结构设计的骨架支撑。它让“模块边界”从逻辑概念落地为编译期可验证的物理约束——跨包调用直接失败，而非运行时报错或靠文档约定。
用包名体现模块职责与层级
包名不是路径别名，而是服务边界的语义声明。微服务中每个独立部署单元（如 user-service、order-service）应有专属顶层包前缀，再按职责分层：
- com.company.user.api：只放 public 接口类（如 UserController、UserDTO），对外提供稳定契约
- com.company.user.spi：放 public 接口 + default 回调（如 UserValidatorHook），供插件扩展但不暴露实现
- com.company.user.internal：大量 default 工具类、Builder、Event、Config —— 外部连 import 都无法通过
默认权限（无修饰符）作为模块内协作主通道
同一微服务模块内的强耦合类，应统一放在语义化子包下，并用默认权限暴露协作入口：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 订单创建流程中的 OrderBuilder、OrderValidator、InventoryDeductor 全部放在 com.company.order.internal
- 它们共用的状态字段（如 builder.status）、解析方法（AmountParser.parse()）全部不加修饰符 → 同包畅通，跨包不可见
- 避免把 default 成员散落在 com.company.common 这类泛化包里，否则等于向所有模块开放
跨模块通信必须走 public API 层，禁用包级依赖
微服务强调松耦合，模块间不能靠“同包可见”绕过接口契约：
- user-service 调用 order-service，只能通过 com.company.order.api.OrderServiceClient（public 接口）
- 禁止直接依赖 com.company.order.internal.* 或 com.company.order.spi.* 中的 default 类
- 构建时若发现跨模块引用了非 api 包，应视为编译错误，CI 流程中可配置 Checkstyle 或 ArchUnit 拦截
警惕多模块同名包导致的默认权限失效
Maven 多模块项目中，不同 module 若都定义了 com.company.shared.util，即使物理路径隔离，打包后 classpath 合并仍会触发“同包可见”——default 成员意外互通：
- 解决方案：每个模块使用唯一包前缀，如 com.company.user.shared 和 com.company.order.shared
- 或启用 JPMS（module-info.java），用
requires和exports精确控制包导出范围 - 不启用 JPMS 时，需靠代码扫描工具识别“伪同包”越界调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
