静态导入只导入静态成员，不自动导入类；import static java.lang.system.* 后仍需 import java.io.printstream 才能用 out.println；通配符静态导入易引发歧义和维护问题，应优先导入具体成员。
静态导入后 System.out.println 报错：找不到符号？
这是最常踩的坑——静态导入不等于自动导入类，它只导入静态成员。如果你写了 import static java.lang.System.out;，那确实能直接用 out.println(...)；但若只导入了 import static java.lang.System.*;，out 是 PrintStream 类型的静态字段，本身没问题，可一旦你删掉 System. 前缀却忘了导入 java.io.PrintStream，编译器就认不出 out 的类型，报 cannot resolve symbol out。
实操建议：
- 静态导入
System.out时，务必确认所在类没被其他同名out变量遮蔽（比如局部变量PrintStream out = ...） - 更稳妥的做法是只导入具体方法，例如
import static java.lang.Math.max;，而非import static java.lang.Math.*;，避免隐式引入一堆不常用的静态方法 - IDE（如 IntelliJ）默认不提示静态导入冲突，需手动开启检查：Settings → Editor → Inspections → Java → Code maturity → “Unused import statement” 和 “Ambiguous static reference”
为什么 import static java.util.Collections.*; 会让 emptyList() 调用变慢？
不是真的变慢，而是编译期解析开销和运行期歧义风险上升。静态导入通配符后，所有同名静态方法（包括重载版本）都进入当前作用域。当你写 emptyList()，编译器得在 Collections、Arrays（如果也静态导入了）、甚至你自己写的工具类里逐个匹配泛型签名，容易触发“reference to emptyList is ambiguous”错误。
常见错误现象：
立即学习“Java免费学习笔记（深入）”；
- 编译失败，提示
reference to emptyList is ambiguous, both method emptyList() in Collections and method emptyList() in MyUtils match - IDE 自动补全列出十几个
emptyList，选错一个导致泛型擦除后类型不匹配
性能影响其实微乎其微，但维护成本陡增。真实项目中，团队代码审查往往直接拒收 .* 静态导入。
Spring Boot 测试里用 @MockBean 还需要静态导入 Mockito 方法吗？
不需要，而且强烈不建议。Spring Test 已经封装了常用行为（如 when(...).thenReturn(...)），但如果你手动静态导入了 org.mockito.Mockito.*，就可能和 Spring 自带的 Mockito 版本冲突——尤其当项目依赖多个测试库（如 mockito-core 和 mockito-inline）时，verifyNoInteractions() 这类新方法可能因类加载顺序不同而找不到。
使用场景决定取舍：
- 单元测试中只用
when/verify等基础方法 → 直接用全限定名或普通导入，避开静态导入 - 需要大量
ArgumentMatchers（如anyString()、eq(123)）→ 可静态导入org.mockito.ArgumentMatchers.*，但必须锁定版本，且禁止通配符导入整个Mockito类 - Gradle 项目中，在
testImplementation里显式声明mockito-core版本，避免传递依赖混入旧版
Java 9+ 模块系统下，静态导入会破坏 requires 声明的可见性吗？
不会破坏，但会掩盖模块边界问题。静态导入本身不改变模块访问规则——如果 A 模块没声明 requires B，即使你在 A 中静态导入 B 的静态方法，编译仍会失败。但开发者容易误以为“能导入就能用”，忽略 module-info.java 里漏写 requires。
容易被忽略的地方：
- 模块化项目中，静态导入的类必须已由模块系统导出（
exports），否则即使requires了，编译器也会报package xxx is not visible -
import static不会触发模块服务加载（uses/provides），别指望靠它激活 SPI 实现 - 使用 JLink 打包时，静态导入不会让未使用的类进入运行时镜像——这点比普通 import 更干净
真正复杂的是混合使用：同一个类里既有普通 import，又有静态 import，还有 module-info 的 requires，三者权限不一致时，编译错误信息极其晦涩，往往要先注释掉静态导入才能定位到真正的模块缺失点。
