javaweb项目目录结构

一个JavaWeb项目从磁盘上看，目目通常长这样：

 src/ ├── main/ │ ├── java/ │ │ └── com/example/ │ │ ├── controller/ │ │ ├── service/ │ │ ├── dao/ │ │ └── entity/ │ ├── resources/ │ │ ├── mapper/ │ │ ├── application.yml │ │ └── static/ │ └── webapp/ │ ├── WEB-INF/ │ │ ├── web.xml │ │ └── views/ │ └── index.html └── test/ └── java/ 

这结构看着规矩，录结但真正折磨人的目目是WEB-INF和resources的边界。很多新人第一次部署时，录结把jsp扔进resources，目目服务器找不到页面，录结白屏半天。目目后来才明白，录结webapp才是目目Web容器的“根目录”，而resources里的录结东西会被打包进classpath，根本不参与URL映射。目目

我见过一个老项目，录结web.xml里配了十几个Servlet映射，目目WEB-INF/views下堆了上百个JSP，录结文件名从user_list_final_2018.jsp到user_list_final_2018_final2.jsp都有。目目每次改需求，先得用IDE的全局搜索确认哪个文件是“当前生效版”。后来拆成Spring Boot，webapp整个消失了，JSP换成了Thymeleaf模板，templates目录直接放在resources下——但核心的controller/service/dao分层，跟十年前几乎没变。

这目录结构的本质，是“约定优于配置”的产物。Maven把java和resources分开，是为了区分编译期和运行期的资源处理方式：.java要编译成.class，而.properties、.xml、图片这些原样拷贝。至于webapp，它是个特例，专门给Servlet容器看的——Tomcat启动时会把webapp下的内容直接映射成站点根路径。

很多团队习惯把SQL脚本也塞进resources，跟Mapper XML放一起。这做法不坏，但容易让目录膨胀。我见过最夸张的一个项目，resources下光SQL备份就有200多个文件，文件名带日期，schema_20240101.sql、schema_20240115_backup_fix.sql，最后连DBA都分不清哪个是最新的。后来改成用Flyway管理数据库版本，resources/db/migration下按版本号命名，这才消停。

还有个小细节容易被忽略：test目录下的结构应该跟main/java一一对应。但现实中很多项目偷懒，测试类全堆在test/java根包下，没有按业务模块分包。等测试用例多了，IDE的测试运行列表按字母排序，找某个Service的测试得翻好几页。更好的做法是让测试类名和被测类名保持一致，比如UserServiceTest对应UserService，目录路径也尽量对齐。

如果你用的是Maven的war插件，注意webapp目录下还有个META-INF的隐藏空间——实际上多数项目用不到，但如果你要自定义context.xml或者数据源，就得知道往那儿放。Spring Boot内嵌Tomcat后，连web.xml都省了，配置全挪到application.yml里，但src/main/java和src/main/resources这两个目录的核心地位从未动摇。

看一个JavaWeb项目，先扫一眼pom.xml里的打包方式（war还是jar），再瞄一眼webapp是否存在，基本就能判断它是老派SSH项目还是Spring Boot新项目。目录结构本身不是银弹，但它像骨架——骨架歪了，后面长出来的肉（业务代码）必然别扭。你问怎么才算“标准”？没有标准，只有适不适合你的部署方式和团队习惯。但有一条底线：别让任何人需要在WEB-INF里翻版本号。