Java 25 import module 怎么减少跨包导入：java.base 可见范围与命名冲突处理

Java 25 的 import module 适合解决一种很具体的麻烦：一个类同时要用 java.util、java.io、java.net 等基础 API，文件顶部堆了很多按包导入。改成 import module java.base; 后，编译器会按模块导入其导出的公共顶层类型，但它不会把第三方 classpath 包或未导出的包变成可见。

import module 是按模块的按需导入，不是“把所有类塞进当前命名空间”；遇到同名类型时，保留一个明确的单类型导入即可消歧。

先把 import module 的适用范围划清

JEP 511 在 Java 25 中将模块导入声明定稿。它导入的是模块导出的包中的公共顶层类和接口，以及当前模块因读取该模块而间接读取模块所导出的类型。

这和传统的 import java.util.*; 不同：后者只覆盖一个包；import module java.base; 的范围由 java.base 的模块描述决定。它也不是把模块里的内部实现类暴露出来，未导出包仍然不能靠这条声明访问。

用 java.base 验证一份最小代码

把下面文件保存为 ImportModuleDemo.java，用 JDK 25 编译。这里故意同时使用 List、ArrayList、Path 和 StringReader，它们来自不同的 java.base 导出包。

import module java.base;

public class ImportModuleDemo {
    public static void main(String[] args) {
        List names = new ArrayList();
        names.add("java.base");
        Path current = Path.of(".").toAbsolutePath();
        System.out.println(names + " -> " + current.getFileName());
    }
}

如果编译器接受这份文件，说明模块导入和 classpath 启动方式可以一起使用；当前源文件不必属于显式命名模块。实际项目仍要用 JDK 25 编译，因为旧版本并不认识这条语法。

遇到同名类型时怎样保留可读性

按模块导入方便，但也可能让两个模块里的类型名同时进入候选集合。此时不要靠删除一大片导入来碰运气，优先给真正使用的类型增加单类型导入，或直接使用限定名。

import module java.base;
import java.sql.Date;

public class DateChoice {
    static Date readSqlDate(long epochDay) {
        return Date.valueOf(java.time.LocalDate.ofEpochDay(epochDay));
    }
}

这个例子把 java.sql.Date 写成单类型导入，把 java.time.LocalDate 写成限定名。单类型导入表达了业务选择，后续读代码的人不需要再猜 Date 来自哪个包；这一步的结果就是编译器消歧。

从传统导入迁移时建议保留的检查顺序

1. 先确认构建机和 IDE 使用 JDK 25，否则语法检查会在最早阶段失败。
2. 查看目标模块的 module-info.java 或官方模块摘要，确认需要的包确实 exported。
3. 只把重复且稳定的基础包导入替换为模块导入，第三方库仍按它们自己的模块或包声明处理。
4. 重新编译并处理同名类型冲突；对公共 API 代码，优先使用明确的单类型导入。

这里的关键是“减少噪声”，不是追求文件顶部只有一条 import。团队代码如果经常需要知道类型来源，保留少量显式导入反而更容易维护。

相关问题：模块导入的边界

没有 module-info.java 就不能使用吗？

可以。模块导入声明既能出现在显式模块的源文件中，也能出现在只通过 classpath 编译和运行的源文件中。

import module 会导入模块中的所有类吗？

不会。它按需导入导出包里的公共顶层类和接口；未导出包、非公共类型和不满足读取关系的类型不在范围内。

它能替代第三方库的全部 import 吗？

不能直接这样推断。第三方库是否可按模块导入取决于它是否提供可读取的模块描述和导出包，仍应以该库的模块文档与构建配置为准。

速查：什么时候采用这条声明

• 适合：基础 API 跨多个导出包、导入列表重复、项目统一使用 JDK 25。
• 谨慎：公共库需要兼容 Java 24 或更早版本，或团队依赖 IDE/编译器插件尚未升级。
• 不适合：想访问模块内部包，或试图用它掩盖第三方依赖没有正确声明的问题。

import module 解决的是导入组织问题。把它当作一层按模块的可见性声明来使用，先确认版本和导出边界，再用单类型导入处理冲突，迁移后的代码才会既短又清楚。