target 是 maven 默认编译输出目录，存放 class 文件、打包产物等构建结果；mvn clean 唯一作用是删除 target；ide 与 maven 编译路径不一致易致 noclassdeffounderror 等问题。
target 文件夹是 Maven 编译的默认输出目录
Maven 默认把编译后的 .class 文件、打包产物（如 jar 或 war）、生成的资源和临时构建文件，全扔进项目根目录下的 target 文件夹里。它不是你手动建的，也不是 Git 要跟踪的——它是纯“结果”，类似前端项目的 dist 或 build 目录。
常见错误现象：java.lang.NoClassDefFoundError 有时就因为 IDE 没刷新 target 里的新 class，或者你改了代码但没重新 mvn compile，还在跑旧的 .class。
- 不要手动修改
target里的任何文件——改了也白改，下次构建就被覆盖 - IDE（如 IntelliJ）通常会自动监听
pom.xml变更并重刷target，但如果发现类没更新，先点Build → Rebuild Project，本质就是清空再重跑mvn clean compile -
target下的classes对应 main 源码编译结果，test-classes对应 test 源码；混淆时注意别把后者当主逻辑去调试
clean 命令不删掉 target 就等于没清理
mvn clean 的唯一正经工作，就是删掉 target 文件夹。它不碰源码、不改配置、不重下依赖——只做这一件事。如果你执行完 mvn clean 后发现 target 还在，基本可以确定：命令根本没跑成功，或者你在错的目录下执行的。
使用场景：切换分支后运行失败、升级 JDK 后类加载异常、IDE 跑不通但命令行可以——这些时候，mvn clean && mvn compile 是比重启 IDE 更快的验证手段。
立即学习“Java免费学习笔记（深入）”；
- 检查当前路径是否为 Maven 项目根目录（有
pom.xml的那层），否则clean什么也不做 - 某些插件（如
spring-boot-maven-plugin）会在target里额外生成original-*.jar，它们也会被clean干掉，不用单独处理 - CI 环境中必须加
clean，否则旧构建残留可能污染新构建（尤其多模块项目里跨模块依赖未更新时）
IDE 缓存和 target 不同步是高频调试陷阱
IntelliJ 默认用自己的一套编译器（而非调 Maven），它把 class 输出到 out 目录；而 Maven 命令行始终写 target。两者不一致时，你点 “Run” 可能跑的是 out 里的老版本，但 mvn test 却跑 target 里的新版本——结果对不上，怀疑人生。
参数差异：IntelliJ 的 Build → Build Project 默认不触发 resources:copy-resources 或 annotationProcessor，而 mvn compile 会完整走生命周期。
- 统一用 Maven 构建：在 Settings → Build → Build Tools → Maven → Runner，勾选
Delegate IDE build/run actions to Maven - 删
target后别忘了也清 IDEA 的缓存（File → Invalidate Caches and Restart），否则它可能从索引里“恢复”已删除的 class - 看日志里实际加载的 class 路径：启动时加
-verbose:class，确认加载的是target/classes/...还是out/production/...
target 里不该出现源码或配置文件的副本
正常情况下，target/classes 里只有编译产物和拷贝过去的 src/main/resources 内容；如果这里出现了 .java、pom.xml 或 src/ 子目录，说明资源拷贝配置写错了，比如 maven-resources-plugin 的 <includes></includes> 误配了 **/*.java。
性能影响：多余文件增大 jar 包体积，拖慢部署；更严重的是，某些类加载器（如 Spring Boot 的 LaunchedURLClassLoader）会扫描整个 classpath，遇到非法 class 文件可能抛 ClassFormatError。
- 检查
pom.xml中是否有自定义的resources配置，重点看<directory></directory>和<includes></includes>是否越界 - 用
jar -tf target/*.jar | grep "\.java"快速验证最终包里有没有源码混入 - IDEA 中右键
target/classes→Open in Terminal，直接ls -R扫一眼结构最省事
真正麻烦的从来不是 target 本身，而是它和 IDE 编译状态、Maven 生命周期、类加载路径这三者的隐式耦合。每次怀疑构建有问题，先盯住 target 是否干净、是否被正确生成、是否被真实加载——绕开这个，其他排查都是在猜。
