import用于导入类而非包，import java.util.*仅让编译器在java.util中查找未限定名类；import static则将静态成员直接引入作用域，提升可读性需权衡清晰度与命名冲突风险。
import 是用来导入类，不是导入包
很多人以为 import java.util.* 是“导入整个包”，其实它只是告诉编译器：当代码里出现未限定名的类（比如 ArrayList），请去 java.util 里找。实际生效的仍是具体类，不是包本身。
常见错误现象：import java.util; 编译报错 —— 因为 import 后面必须跟类名或通配符 *，不能只写包名。
-
import java.util.ArrayList;：只导入单个类，推荐用于明确依赖的场景 -
import java.util.*;：导入该包下所有**已编译的公开类**（不包括子包），但不会提升性能，仅影响编译期解析 - 重复 import 同一个类（比如两个不同包里的
Date）会导致编译错误，必须显式用全限定名解决
import static 是为省掉类名前缀，不是为了“导入静态方法”这个动作本身
import static 的本质是把某个类的静态成员（字段或方法）直接拉进当前作用域，让你能写 assertEquals(1, a) 而不是 Assert.assertEquals(1, a)。但它不改变语义，也不影响运行时行为。
容易踩的坑：
立即学习“Java免费学习笔记（深入）”；
- 过度使用
import static org.junit.Assert.*会让代码难以分辨哪些是静态方法、哪些是本地变量 —— 比如fail()看起来像普通函数调用，其实是Assert.fail() -
import static java.lang.Math.*;后，sqrt(4)可以直接用，但若同时import static java.util.Objects.*;，又定义了本地变量sqrt，就会冲突 - 不能
import static构造器（即new XXX()不受其影响）
什么时候该用 import static？看调用频次和上下文清晰度
它适合高频、无歧义、领域内公认的静态成员。JUnit 的断言、Math 的常量、Collections 的工具方法是典型场景；业务逻辑里自定义的静态工具方法，除非团队共识明确，否则慎用。
实操建议：
- 测试类中常用
import static org.junit.Assert.*;或更细粒度的import static org.junit.Assert.assertEquals; - 数学计算密集型代码可考虑
import static java.lang.Math.PI;和import static java.lang.Math.sqrt;，但避免import static java.lang.Math.*; - 永远不要
import static名称通用的静态字段（比如叫VALUE、TYPE的），极易引发命名污染
IDE 自动导包默认不开 import static，这是有道理的
多数 IDE（IntelliJ / Eclipse）默认只做普通 import，需要手动开启或按快捷键触发 import static。这不是功能缺失，而是设计克制 —— 静态导入会削弱代码可读性边界。
真正难处理的是隐式依赖：比如你用了 Stream.of()，IDE 自动加了 import java.util.stream.Stream;，但如果你后续又写了 of(1,2,3) 并启用了 import static java.util.stream.Stream.of;，别人读代码时得倒查才知道这 of 来自哪里。
所以，哪怕省了一次键盘输入，也要多问一句：这个静态成员的来源，在当前文件里是否一眼可辨？
