如何在Java里导入类_Javaimport语法使用说明_技术教程

import语句必须位于package声明之后、类定义之前；不可在方法或类体内；静态导入需加static关键字；通配符导入有命名冲突风险；默认包中的类无法被其他包import。

import 语句必须写在类定义之前

Java 的 import 不是运行时加载机制，而是编译期的符号引用声明。它只影响源码中类名的解析，不参与字节码生成或类加载过程。所以 imp

ort 必须出现在 package 声明之后、class 或 interface 定义之前，否则编译器直接报错：error: class, interface, or enum expected。

import 不能写在方法内部、不能写在类体中（比如写在 public void foo() { ... } 里）
多个 import 可以并列，顺序无关，但通常按字母或包层级组织便于阅读
即便只用一次的类，也必须 import（除非用完整限定名，如 java.util.ArrayList）

静态导入要显式写 static 关键字

想直接用工具类的静态方法（比如 Objects.equals() 或 Collections.emptyList()），得用 import static，而不是普通 import。漏掉 static 就会编译失败，提示“cannot resolve symbol”。

正确写法：import static java.util.Objects.equals; 或 import static java.util.Collections.*;
错误写法：import java.util.Objects.equals;（语法非法）或 import java.util.Objects;（只能用 Objects.equals()，不能直接写 equals()）
过度使用静态导入会让调用来源模糊，尤其多个静态导入同名方法时（如 Stream.of() 和 Arrays.stream() 都有 of()），容易引发歧义

通配符 import * 有隐藏风险

import java.util.*; 看起来省事，但实际会引入整个包下所有 public 类，可能触发命名冲突或意外遮蔽（shadowing）。JDK 自身就存在这类陷阱：比如 java.sql.Date 和 java.util.Date 同时被 * 导入时，若未显式指定，编译器无法推断你想要哪个。

编译器遇到歧义会报错：reference to Date is ambiguous
IDE（如 IntelliJ）默认不自动补全 * 导入，也是出于可维护性考虑
现代项目普遍推荐显式导入（explicit import），哪怕多敲几行，也比后期排查冲突高效
构建工具如 Maven 的依赖传递不会影响 import 行为——它只管你源码里写了什么，不管这个类最终从哪来

默认包里的类无法被其他包 import

如果一个 Java 文件没写 package 声明，它就在默认包（unnamed package）里。而根据 JVM 规范，**其他任何包里的类都不能 import 默认包中的类**。这是硬性限制，不是 IDE 或构建配置问题。

现象：A.java 在默认包，B.java 在 com.example 包，B 中写 import A; → 编译报错：error: cannot find symbol
解决方式只有两个：给 A.java 加上 package 声明；或把 B.java 也挪到默认包（不推荐，破坏模块边界）
即使两个类在同一目录、同一模块、甚至同一 jar，只要包声明不同，默认包仍是“不可见孤岛”

package com.example;
import java.util.List;
import static java.lang.Math.max;
public class Main {
public static void main(String[] args) {
List list = new java.util.ArrayList<>(); // 可用全限定名绕过 import
int bigger = max(3, 5); // 静态导入后直接用
}
}

真正容易卡住人的，往往不是语法记不住，而是默认包可见性、静态导入缺 static、以及 * 导入引发的冲突——这些错误不报红在 import 行，而是等你真正用到那个类或方法时才爆发。