本文澄清Maven模块间依赖与Java import语句的本质区别：groupId:artifactId是Maven构建时的坐标标识，而import语句依赖的是Java源码的实际包声明（package），二者完全解耦；未声明package的类属于默认包，不可显式import。
本文澄清maven模块间依赖与java import语句的本质区别：`groupid:artifactid`是maven构建时的坐标标识，而`import`语句依赖的是java源码的实际包声明（package），二者完全解耦；未声明package的类属于默认包，不可显式import。
在Maven多模块项目中（如 proj-root → proj-lib + proj-cli），子模块间的依赖关系由Maven反应器（Reactor）在构建期自动解析——只要proj-cli/pom.xml中正确定义了对proj-lib的依赖（例如 <dependency><groupid>com.example</groupid><artifactid>proj-lib</artifactid><version>${project.version}</version></dependency>），且整个项目从proj-root目录执行mvn compile或mvn install，Maven就能确保proj-lib的编译产物（.class文件）被正确加入proj-cli的编译类路径（classpath）。但这与Java语言层面的import语法毫无关系。
关键在于：Java的import语句只识别源码中的package声明，而非Maven的groupId或artifactId。例如：
// ❌ 错误：Util.java 未声明 package，位于默认包（unnamed package）
// src/main/java/Util.java
public class Util {
public static void doSomething() { /* ... */ }
}此时，即使proj-cli成功依赖并使用了Util类（如直接调用Util.doSomething()），你也无法编写import com.example.proj-lib.Util;或任何其他显式import语句——因为Java语法禁止导入默认包中的类。IDE（如IntelliJ）可能允许你“无import调用”，但这属于编译器对默认包的宽松支持，且严重违反Java工程实践。
✅ 正确做法是为所有类显式声明有意义的包路径：
用于 inference.sh 的 JavaScript/TypeScript SDK，可运行 AI 应用、构建代理、集成 150+ 模型。包名：@inferencesh/sdk（npm install），完整 TypeScript 支持。
立即学习“Java免费学习笔记（深入）”；
// ✅ 正确：Util.java 明确归属 Java 包
// proj-lib/src/main/java/com/example/proj/lib/Util.java
package com.example.proj.lib;
public class Util {
public static void doSomething() { /* ... */ }
}随后，在proj-cli中即可规范导入：
// proj-cli/src/main/java/com/example/proj/cli/Main.java
package com.example.proj.cli;
import com.example.proj.lib.Util; // ✅ 完全合法且推荐
public class Main {
public static void main(String[] args) {
Util.doSomething(); // 清晰、可维护、无歧义
}
}⚠️ 注意事项：
-
命名冲突防范：Java包名应遵循反向域名约定（如
com.example.proj.lib），这与MavengroupId（通常也为com.example）形成自然映射，但二者独立演进。包名决定import路径，groupId仅用于Maven仓库定位和依赖解析。 - 默认包风险：避免将任何生产代码置于默认包。它不仅导致无法显式import，还会引发反射失败、模块系统（Java 9+）不兼容、测试框架加载异常等问题。
-
IDE行为提示：IntelliJ等IDE在“无package”场景下允许跨模块调用，是因其内部类路径合并机制，但该行为不可移植（如命令行
javac会报错），且掩盖了架构缺陷。
总结：Maven模块依赖解决的是构建时的二进制可见性，而Java import解决的是编译时的源码可读性与命名空间管理。二者协同工作的前提是——每个类都拥有明确、规范、非空的package声明。将包结构设计纳入初始架构，是保障多模块项目长期可维护性的基石。
