核心是用反向域名前缀（如com.example）确保全球唯一性，再按业务域逐层细化（如ecommerce.order.api），使全限定名可读且无歧义；包路径必须与文件系统严格一致。
Java 包名命名规范防止命名空间冲突，核心是用“全局唯一前缀 + 清晰业务路径”构造全限定名，让 JVM 能无歧义识别每个类。
用反向域名确保全球唯一性
包名前缀采用组织拥有的互联网域名逆序形式（如 com.example、org.springframework），因为域名由 ICANN 统一注册，天然具备全球唯一性。只要不共用域名，不同团队的包名就不会撞车。个人开源项目可用 io.github.用户名 或 com.github.用户名；内部学习项目可临时用 com.example，但切忌在协作或发布场景中使用 test、demo、myapp 这类无归属标识的名称。
层级结构表达业务边界
在唯一前缀后，按实际职责逐层细化，常见模式为：域名 → 项目/产品 → 模块 → 分层 → 类型。例如：
- com.example.ecommerce.order.api（订单模块对外接口）
- com.example.ecommerce.order.infra.persistence（订单模块持久化实现）
- com.example.billing.invoice.render.pdf（开票模块的 PDF 渲染组件）
这种写法让包名本身成为“可读的路径说明书”，既避免模糊命名（如单独的 util 或 common），也防止跨域混杂（如 order 模块里出现 payment 相关类）。
立即学习“Java免费学习笔记（深入）”；
严格匹配目录与强制全限定名识别
Java 要求 package 声明必须与文件系统路径完全一致。比如声明 package com.example.user.auth;，源文件就必须放在 src/com/example/user/auth/ 下。编译器和类加载器都依赖这个约定查找类——路径错、包名错、类就加载失败。JVM 只认全限定名（如 com.example.user.auth.UserService），同名类只要包路径不同，就是完全不同的类型，可安全共存。
团队落地需配套机制
再好的规范也需要执行保障：
- 在代码规范文档中明确定义每级包名含义（如 infra 表示基础设施，app 表示启动入口）
- 用 Checkstyle 或 SonarQube 拦截违规包名（如禁止 com.example.util 单独存在）
- 新模块引入时由架构组评审包路径是否符合领域边界
包不是越深越好，也不是越短越妙。关键是让每个点号分隔的部分都有明确语义，且整个路径能经得起推敲。
