静态导入不制造冲突但暴露命名冲突，解决关键在于明确来源、限制范围、主动区分：本类定义优先于静态导入；禁用通配符导入，按需单导；歧义时用全限定名；检查依赖树防版本重复。
Java 中静态导入本身不制造冲突，但会让已存在的命名冲突立刻暴露出来。真正要解决的，不是“怎么导入”，而是“如何让同名静态成员在当前作用域能被唯一识别”。核心思路是：明确来源、限制范围、主动区分。
明确优先级：本类定义 > 静态导入
当本类中定义了与静态导入同名的静态方法或字段时，编译器默认优先调用本类成员。例如：
- 你静态导入了 org.apache.commons.lang3.StringUtils.isBlank
- 又在当前类里写了 public static boolean isBlank(String s) { ... }
- 此时直接写 isBlank("test")，执行的是本类的方法
若想调用导入的那个，必须显式加类名限定：StringUtils.isBlank("test")。
避免通配符导入，按需单导
使用 import static xxx.* 是冲突高发区，尤其当多个工具库提供相似功能时（如 Guava、Apache Commons、Spring 的 checkNotNull 或 isBlank）。推荐做法：
- 只导入真正高频、语义清晰的单个成员，例如 import static java.util.Objects.requireNonNull;
- 禁用 import static org.mockito.Mockito.*; 这类全量导入
- 如果两个库都提供了 of()，就只导入一个，另一个始终用全限定名调用
用全限定名消除歧义
当编译报错 "reference to XXX is ambiguous"，说明至少两个静态导入来源都提供了同名成员。这时最直接的解法是：
- 删掉其中一个 import static 语句
- 保留一个，另一个改用 ClassName.methodName(...) 方式调用
- 例如同时导入了 Collections.emptyList() 和 ImmutableList.of()，就删掉前者，把 emptyList() 改成 Collections.emptyList()
检查依赖树，防止隐式重复引入
有时冲突并非来自你写的 import，而是项目间接引入了多个版本的同一工具包（比如 commons-lang3:3.12 和 commons-lang3:3.14），导致两个不同 jar 包里的 StringUtils 类都被导入。可执行：
- mvn dependency:tree -Dincludes=commons-lang3 查看实际依赖路径
- 在 IDE 中展开 “Maven Dependencies”，确认是否真有两个不同版本
- 通过
排除冗余传递依赖
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
