作为 Java 后端开发者，每天和代码打交道时，项目结构就像 “建筑图纸”—— 它决定了代码如何组织、功能如何分层，甚至影响团队协作的效率。今天我们就以一个典型的 Spring Boot + Maven 项目为例，拆解这份 “图纸” 里的每一个细节。

一、项目的 “容器”：根目录与开发工具痕迹

打开项目，最外层的根目录（比如示例中的 demo，路径 D:\javaproject\demo）是一切的起点。它像一个 “大抽屉”，把源代码、配置文件、依赖库，甚至最终打包好的应用，都整整齐齐收纳其中。

根目录里往往会有一个 .idea 文件夹 —— 这是 IntelliJ IDEA（Java 开发者常用的 IDE）的 “专属区域”。它存储着 IDE 的个性化配置：比如你习惯的代码缩进风格、项目运行时的 JVM 参数、甚至某个类的折叠状态，都存在这里。但注意，这些配置只服务于开发工具，和业务逻辑本身毫无关系，团队协作时也通常不会把它提交到代码仓库（因为每个人的 IDE 习惯可能不同）。

二、源代码的 “核心区”：src 目录的分层艺术

src 目录是源代码的 “心脏”，被清晰地分为 main（主应用代码）和 test（测试代码）两部分。我们先聚焦于承载业务逻辑的 main。

（1）src/main/java：Java 代码的 “分层帝国”

src/main/java 目录下，Java 代码以 ** 包（Package）** 为单位组织，遵循 “反向域名” 的命名规范（比如 com.example.demo）—— 这是为了避免不同项目的类名冲突（想象一下，要是大家都用 User 类，不加包名区分，岂不乱套？）。

在这个 “基础包”（如 com.example.demo）下，代码被分成了多个 “职能部门”：

• DemoApplication：项目的 “启动钥匙”
  带 @SpringBootApplication 注解的 DemoApplication 类，是 Spring Boot 应用的入口。运行这个类的 main 方法，Spring 会启动容器，自动加载配置、扫描组件，整个应用就 “活” 了起来。可以说，它是项目的 “总开关”。

• controller：前后端的 “传令官”
  controller 包下的类，负责接收前端的 HTTP 请求，然后调用 service 层处理业务，最后把结果返回给前端。比如，一个 UserController 可能有 /api/user/login 接口，接收用户登录参数，调用 UserService 验证身份，再返回登录结果。在前后端分离的项目中，controller 就是前端眼里的 “接口集合”。

• entity：数据的 “实体映射”
  entity 包存放 “领域模型类”，通常和数据库表一一对应。比如 Department 类，可能对应数据库里的 department 表，类的属性（如 id、deptName）就是表的字段。它是 “数据库数据” 在 Java 世界的 “化身”。

• mapper：数据库的 “操作工”
  若用 MyBatis 这类 ORM 框架，mapper 包就是操作数据库的 “入口”。这里的接口定义了 SQL 的映射规则，比如 DepartmentMapper 里的 List<Department> findAll() 方法，会对应一条 “查询所有部门” 的 SQL。我们不用写复杂的 JDBC 代码，通过调用 mapper 接口，就能间接操作数据库。

• service：业务逻辑的 “大脑”
  service 包是业务逻辑的核心，它一边调用 mapper 获取 / 修改数据，另一边给 controller 提供业务方法。比如，DepartmentService 可能有 addDepartment 方法，里面不仅调用 DepartmentMapper 插入数据，还会做 “部门名称唯一性校验” 等业务规则判断。它是 controller 和 mapper 之间的 “桥梁”，让业务逻辑更集中、更易维护。

（2）src/main/resources：非 Java 资源的 “聚集地”

项目里不只有 Java 代码，还有配置、静态文件、模板等资源，它们都存放在 src/main/resources 中：

• static：静态资源的 “仓库”
  static 目录放 CSS、JavaScript、图片等 “不需要动态生成” 的资源。比如前端页面要用的 logo.png、index.js，都可以丢在这里 —— 浏览器能直接通过路径访问到这些文件（比如 http://localhost:8080/static/logo.png）。

• templates：动态页面的 “模板间”
  如果用 Thymeleaf、Freemarker 等模板引擎，动态 HTML 页面的 “模板” 就存在 templates 里。模板引擎会把模板和数据结合，生成最终的 HTML。不过在前后端分离的项目中，前端自己渲染页面，这个目录的使用频率会降低。

• application.yml：项目的 “配置中心”
  application.yml（也可以用 application.properties）是 Spring Boot 的核心配置文件。数据库连接信息（URL、用户名、密码）、服务器端口（比如把默认的 8080 改成 9090）、日志级别（比如让 DEBUG 级别的日志显示出来）…… 项目的 “可配置项”，几乎都在这里定义。它就像给应用定制 “运行规则” 的手册。

（3）src/test：代码质量的 “试金石”

src/test 目录存放测试代码，包括单元测试、集成测试等。它的结构通常和 src/main/java“镜像对称”—— 比如 main 有 controller 包，test 就会有 controller 的测试类，专门验证控制层的逻辑是否正确。通过测试，我们能提前发现代码漏洞，保障项目质量。

三、构建与输出：target 目录的 “幕后工作”

写好的代码，最终要编译、打包成可运行的程序。target 目录就是 Maven（或 Gradle）这类构建工具的 “工作区”，存放构建后的产物：

• target/classes：运行时的 “真实代码”
  这里存储的是编译后的 Java 字节码（.class 文件），以及 resources 目录里需要随项目运行的资源（比如 templates、application.yml）。换句话说，项目运行时，JVM 真正加载的就是这里的内容 —— 相当于把 “源代码” 转换成了 “可执行的机器语言”。

• generated-sources/annotations：自动生成的 “辅助兵”
  有些工具（比如 Lombok、MapStruct）会在编译阶段 “自动生成代码”。比如 Lombok 能帮我们自动生成 getter/setter 方法，这些生成的代码就存放在 generated-sources/annotations 里。我们不用手动写重复代码，工具会悄悄帮我们完成。

四、项目的 “管家们”：配置与辅助文件

根目录下还有几个 “小文件”，却在项目管理中扮演关键角色：

• pom.xml：Maven 的 “指挥中心”
  pom.xml 是 Maven 项目的核心配置文件。它管理着项目的依赖（比如要引入 Spring Boot 框架、MySQL 驱动，只需要在这里配置），也定义着构建流程（比如编译用的 JDK 版本、打包成 JAR 还是 WAR）。有了它，Maven 能自动下载依赖、编译代码、打包应用，堪称项目的 “大管家”。

• .gitignore：版本控制的 “过滤器”
  如果用 Git 做版本管理，.gitignore 文件会指定 “哪些文件 / 目录不需要提交到代码仓库”。比如 target 目录（因为它是编译生成的，每次构建都会变）、IDE 的配置目录（如 .idea），都可以通过它 “过滤” 掉，避免仓库里存一堆无用文件。

• HELP.md：项目的 “说明书”
  Spring Boot 项目默认会生成 HELP.md，里面简单介绍项目的基本信息（比如怎么运行、核心依赖是什么）。新同事接手项目时，能通过它快速了解项目概况。

五、IDE 里的 “隐形助手”

在 IntelliJ IDEA 中，还有两个容易被忽略但很重要的区域：

• “外部库”：这里展示了项目依赖的第三方库。比如 Spring 框架的 spring-core、spring-web，MySQL 的驱动包，都能在这里看到。Maven 会根据 pom.xml 自动下载这些库，“外部库” 让我们直观知道项目 “站在哪些巨人的肩膀上”。

• “临时文件和控制台”：IDE 会在这里存一些临时文件（比如编译过程中的中间文件），也会显示程序运行的日志、控制台输出。调试代码时，我们常通过这里的输出（比如异常栈信息）来排查问题。

写在最后

Spring Boot + Maven 的项目结构，是 “约定大于配置” 思想的完美体现 —— 通过分层的包结构、明确的资源目录，让代码职责清晰、易维护；再配合 Maven 的构建能力、IDE 的辅助，从开发到运行的全流程都变得 “井然有序”。

理解了这些结构的意义，无论是接手老项目，还是从零搭建新应用，你都能更快摸清脉络，少走 “结构混乱” 的弯路。毕竟，清晰的结构，是写出好代码的第一步～