企业级spring boot项目目录结构应按职责分层+按业务划包,根包为com.example.project,application.java须置于顶层;controller、service、repository、model分层清晰,config仅放配置类,resources下static/templates等路径须严格遵循约定,补充exception、dto/vo/query、util、aspect等关键包。

企业级 Spring Boot 项目的目录结构不能只图“能跑”,关键是要支撑多人协作、长期迭代和快速定位问题。核心原则就一条:按职责分层 + 按业务划包,两者结合,不混用。
主包结构必须从根包开始,且 Application.java 放最顶层
这是 Spring Boot 自动扫描的起点。比如项目域名是 example.com,根包就该是 com.example.project,Application.java 必须放在这个包下,不能嵌套在 controller 或 config 里。否则 @ComponentScan 默认扫不到其他组件,很多 starter 功能会失效。
- 错误示例:
com.example.project.web.Application.java(Web 包里启动,service 和 config 可能被漏扫) - 正确示例:
com.example.project.Application.java,其余子包都从它往下展开
分层目录要明确技术职责,每层边界清晰
controller、service、repository、model 这几层是基础骨架,但要注意细节落地:
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
controller:只做请求接收、参数校验(@Valid)、DTO 转换、调用 service,不写业务逻辑;建议按业务域建子包,如
user、order -
service:接口与实现分离,接口放
service,实现类统一进service.impl;@Transactional 标在实现类方法上,不是接口 -
repository:JPA 的 JpaRepository 或 MyBatis 的 Mapper 接口都放这里;实体类(Entity)建议单独放在
domain或model.entity,避免和 DTO、VO 混在一起 - config:只放配置类,如 WebMvcConfigurer、SecurityFilterChain、RedisCacheManager 等;不要把工具类或常量塞进来
资源目录要严格遵循约定路径
Spring Boot 对 resources 下的子目录有默认行为,改路径等于自己绕开自动配置:
-
static/:放 JS、CSS、图片等纯静态文件,可直接通过 URL 访问(如
/js/app.js) - templates/:Thymeleaf、Freemarker 模板必须放这里,否则渲染失败
-
application.yml 是主配置;多环境用
application-dev.yml、application-prod.yml;Nacos 或 Config Server 场景才加bootstrap.yml - 不要新建
conf/或cfg/目录放配置,Spring Boot 不识别
补充关键包,让结构更健壮
标准四层之外,这几个包在企业项目中几乎是标配:
- exception:统一异常处理类(@ControllerAdvice)、自定义异常类型(如 BusinessException)、全局错误码枚举
- dto / vo / query:明确区分数据传输对象(DTO)、视图对象(VO)、查询参数(Query),避免 Entity 直出 API
- util:纯静态工具方法,无状态、不依赖 Spring 容器;含日期、字符串、加密等通用能力
- aspect:日志、权限、审计等横切逻辑,用 @Aspect 实现,不污染业务代码










