Maven构建时看似“跳过”依赖下载，实则是复用本地仓库中已缓存的JAR包；所有依赖统一存储在~/.m2/repository，避免重复下载、保障构建可重现性。
maven构建成功却未下载依赖包？真相与最佳实践全解析。maven构建时看似“跳过”依赖下载，实则是复用本地仓库中已缓存的jar包；所有依赖统一存储在`~/.m2/repository`，避免重复下载、保障构建可重现性。
当你执行 mvn package 并成功生成 target/xxx.jar，却没在 target/ 目录下看到 junit.jar 等依赖——这完全正常，且正是 Maven 设计的精妙所在。
Maven 的依赖管理遵循严格的职责分离原则：
- ✅
target/目录只存放当前项目的构建产物（如编译后的.class文件、测试报告、最终 JAR/WAR 包）； - ✅ 所有第三方依赖（如
junit、spring-core）统一下载并长期缓存在本地仓库（~/.m2/repository）中； - ❌
target/从不存放依赖 JAR——它们不会被打包进你的主 JAR（除非显式配置maven-shade-plugin或spring-boot-maven-plugin等插件做 fat-jar）。
以你运行的 FFT 库为例：
-
pom.xml中声明了<dependency><groupid>junit</groupid><artifactid>junit</artifactid><version>4.12</version><scope>test</scope></dependency>； - Maven 首先检查
~/.m2/repository/junit/junit/4.12/是否已存在junit-4.12.jar； - 若存在（通常首次构建后即缓存），则直接使用，跳过网络下载；
- 编译和测试阶段，Maven 会将该 JAR 自动加入 classpath，但绝不复制到
target/——这是约定大于配置（Convention over Configuration）的核心体现。
? 验证方法：
# 查看本地仓库中 junit 是否已存在 ls ~/.m2/repository/junit/junit/4.12/ # 输出应包含：junit-4.12.jar、junit-4.12.pom、_remote.repositories 等 # 强制刷新依赖（用于排查 stale 缓存） mvn clean compile -U
⚠️ 重要注意事项：
-
不要手动向
target/复制 JAR：这破坏 Maven 的构建契约，会导致mvn test失败、IDEA 项目同步异常、CI 流水线不可重现； -
<scope></scope>决定依赖参与阶段：test（仅测试编译/运行）、compile（默认，参与编译与运行）、provided（如 servlet-api，由容器提供）——不同 scope 的依赖在不同生命周期可见，但全部存于~/.m2/repository； -
本地仓库路径可自定义：在
conf/settings.xml中修改<localrepository>E:/maven-repo</localrepository>，避免 C 盘空间占用或中文路径问题； -
首次构建慢？配阿里云镜像提速：在
settings.xml的<mirrors></mirrors>节点添加：<mirror> <id>aliyunmaven</id> <mirrorOf>*</mirrorOf> <name>阿里云公共仓库</name> <url>https://maven.aliyun.com/repository/public</url> </mirror>
✅ 总结一句话：Maven 不是“没下载”，而是“已缓存、不重复下、不乱放”。理解 ~/.m2/repository 这个中央枢纽，你就真正掌握了 Maven 依赖管理的底层逻辑——它让成百上千个项目共享同一份可信依赖，既高效又可靠。
