Java import语句本质是编译期名称解析助手，不加载类、不影响性能，仅提升简洁性与可读性；分为单类型导入（如import java.util.ArrayList;）、按包导入（import java.util.*;，不递归子包）和静态导入（import static java.lang.Math.PI;），须位于package后、类前，且静态导入仅限public static成员。
Java 的 import 语句本质是编译期的“名称解析助手”，不加载类、不影响性能，只让代码更简洁易读。它分三类：普通类导入、包通配符导入、静态导入。关键不在“导多少”，而在“导得准、用得清”。
普通 import：明确引用类，避免歧义
用于引入其他包中的类或接口，必须写在 package 声明之后、类定义之前。
-
单类型导入最推荐：如
import java.util.ArrayList;或import java.time.LocalDate;—— 依赖清晰，IDE 跳转快，同名类冲突风险低 -
按包导入（*）要节制：如
import java.util.*;会导入 java.util 下所有 public 类（ArrayList、HashMap、Scanner），但不包含子包（如 java.util.concurrent 不会被导入） -
java.lang 包自动导入：String、System、Math 等无需显式 import；但 Math 是类，它的静态方法仍需
import static才能省略前缀
静态导入（import static）：只为高频、无歧义的静态成员减负
它把其他类的 public static 方法或字段 直接拉进当前作用域，让你写 max(3, 5) 而非 Math.max(3, 5)。但它不是语法糖的终点，而是可读性的分水岭。
-
写法分两种：导入指定成员（推荐）
import static java.lang.Math.PI;；或通配符导入全部import static java.lang.Math.*; -
只认 public static：private static、protected static、实例方法、构造器，统统无法导入；拼错大小写（如
math.pi）或访问权限不足都会编译失败 -
冲突时必须显式限定：若同时导入
org.junit.Assert.assertTrue和自定义的MyUtils.assertTrue，编译器报错，此时只能写Assert.assertTrue(...)
哪些场景真适合用静态导入？
不是“能省就省”，而是“省了更清楚”。典型场景有明确上下文支撑：
立即学习“Java免费学习笔记（深入）”；
-
单元测试类：JUnit 或 AssertJ 断言密集，
import static org.junit.jupiter.api.Assertions.*;后写assertEquals(1, a)更聚焦逻辑，不干扰断言意图 -
数学/工具方法高频调用：图形算法中反复用
sin()、cos()、PI，导入Math.*比满屏Math.更干净；集合操作中导入Collections.emptyList()或Arrays.asList()构造小数据也轻量 -
团队共识的工具类：如项目统一使用
StringUtils.isBlank()，且该类稳定、命名唯一，可具名导入import static com.example.utils.StringUtils.isBlank;
哪些情况坚决不用？
静态导入一旦模糊来源，就变成维护负担：
-
通配符导入多个类：比如同时
import static java.util.Collections.*;和import static java.util.Arrays.*;，两者都有asList()，编译直接报错 -
业务类静态方法：如
OrderService.calculateDiscount()导入后写calculateDiscount()，别人读代码根本看不出这是领域逻辑还是通用工具 -
只调用一两次就导入：为一行
Math.abs(x)加一句import static，纯属增加文件头噪音 - IDE 提示变弱的地方：悬停看不到方法来源，重构时容易漏掉依赖，尤其对新成员不友好
