Gradle多模块项目通过声明式project dependency实现模块引用，需在settings.gradle中include模块、子项目中用implementation project(':name')声明依赖，并遵循单向分层依赖原则。
在 Gradle 多模块 Java 项目中，模块间引用不是靠手动复制 JAR 或配置 classpath 实现的，而是通过声明式项目依赖（project dependency）完成的——这是 Gradle 原生支持的核心能力，既安全又可复用。
明确声明子模块依赖关系
在需要调用其他模块的子项目的 build.gradle 文件中，使用 implementation project(':module-name') 语法：
-
implementation表示该依赖参与编译和运行，但不会暴露给本模块的调用方（推荐默认使用） -
project(':service-user')中的路径必须与 settings.gradle 中include的声明完全一致（包括冒号前缀和大小写） - 例如：
web-api模块要使用用户服务，就在其build.gradle中写：dependencies { implementation project(':service-user') }
确保根项目正确识别所有模块
settings.gradle 是模块注册的唯一入口，必须显式 include 所有子模块：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 路径需层级清晰，如
include 'common', 'service-user', 'web-api' - 若模块嵌套较深（如
lib:auth:core），应写为include 'lib:auth:core'，并在文件系统中保持对应目录结构 - 避免同名模块（如两个
:model），否则 Gradle 可能因路径解析歧义引发循环依赖错误
合理设计依赖方向与层级
模块间引用应遵循“单向依赖、分层清晰”原则，防止循环引用和过度耦合：
立即学习“Java免费学习笔记（深入）”；
-
common是基础工具模块，通常不依赖其他业务模块 -
service-user可依赖common，但不应反向依赖web-api -
web-api可同时依赖service-user和common，作为最上层对外暴露接口 - 构建失败提示 “Circular dependency” 时，大概率是某处写了双向
project(...)引用，需检查依赖图
统一版本与共享配置（可选但推荐）
在根项目的 build.gradle 中，可通过 subprojects 或 allprojects 统一应用插件、仓库和基础依赖：
- 例如：所有模块都用 Java 插件、Junit 测试、Maven Central 仓库
- 也可在根项目定义
ext版本常量，子模块通过"org.springframework:spring-core:$springVersion"引用，避免分散写死版本号 - 更高级做法是引入 Spring Boot BOM 或自定义 platform，自动协调跨模块的依赖版本
