Java依赖管理需通过Maven或Gradle声明，而非全局安装；Maven在pom.xml中配置dependency并指定scope，Gradle用implementation/api等关键字控制传递性；手动添加JAR易导致依赖缺失或冲突，应避免。
Java没有“安装库”这回事，只有依赖管理
Java本身不提供类似 pip install 或 npm install 那样的全局库安装机制。所谓“安装第三方库”，实际是让构建工具（如 Maven 或 Gradle）在编译/运行时把对应 JAR 包拉进项目 classpath。你不能像 Python 那样在系统级“装一个 commons-lang”，而必须在每个项目里声明它需要什么版本的 org.apache.commons:commons-lang3。
Maven：在 pom.xml 里声明 dependency 就够了
Maven 是最主流的 Java 依赖管理工具。它不下载到全局目录，而是默认存到本地 ~/.m2/repository，多个项目共享同一份缓存，但各自独立解析依赖树。
添加一个库只需三步：
- 去 MvnRepository 搜索目标库（比如 “lombok”）
- 复制对应版本的
- 粘贴进项目的
pom.xml的
例如引入 Lombok：
立即学习“Java免费学习笔记（深入）”；
org.projectlombok lombok 1.18.34 provided
注意 scope：provided 表示只在编译期需要、运行时不打包；runtime 表示编译不用但运行要；默认是 compile（编译+运行都需）。选错会导致 NoClassDefFoundError 或 IDE 报红但运行正常等反直觉问题。
Gradle：用 implementation 或 api 声明依赖
Gradle 更灵活，但初学者容易混淆 implementation 和 api。它们都影响依赖传递性：
JTBC CMS(5.0) 是一款基于PHP和MySQL的内容管理系统原生全栈开发框架，开源协议为AGPLv3，没有任何附加条款。系统可以通过命令行一键安装，源码方面不基于任何第三方框架，不使用任何脚手架，仅依赖一些常见的第三方类库如图表组件等，您只需要了解最基本的前端知识就能很敏捷的进行二次开发，同时我们对于常见的前端功能做了Web Component方式的封装，即便是您仅了解HTML/CSS也
-
implementation 'com.google.guava:guava:33.2.1-jre'：当前模块用，下游模块看不到这个依赖 -
api 'org.slf4j:slf4j-api:2.0.13'：当前模块用，且下游模块也能直接用它（适合公共 API 层）
如果只是写个普通应用，95% 场景用 implementation 就行。误用 api 会导致依赖泄露，下游莫名其妙多出一堆 transitive 依赖，构建变慢、冲突概率上升。
Gradle 还支持 runtimeOnly、testImplementation 等更细粒度的 scope，和 Maven 的
手动加 JAR？能避免就避免
有人会把下载好的 xxx.jar 放进 lib/ 目录，再在 IDE 里右键 “Add as Library”。这种做法看似简单，实则埋雷：
- 无法自动解决传递依赖（比如你加了
okhttp-4.12.0.jar，但它依赖okio-3.4.0.jar，你得自己找齐） - 不同模块用不同版本时，IDE 可能加载错，运行时报
LinkageError - CI/CD 流水线里完全失效——没
pom.xml或build.gradle，别人拉代码根本跑不起来
除非调试某个未发布快照版、或公司内网无 Maven 私服，否则不要手动放 JAR。
真正麻烦的从来不是“怎么加”，而是“加了之后为什么类找不到”“为什么两个库用的同一个类却版本打架”。这些都要靠理解依赖传递、冲突仲裁（Maven 默认取最近定义的版本）、以及善用 mvn dependency:tree 或 ./gradlew dependencies 查真实依赖图。
