静态导入不引发命名冲突但暴露已有冲突，编译器遇同名静态成员即报“reference to XXX is ambiguous”；需注重方法命名唯一性，优先选用带业务前缀的静态方法，避免泛化名称；本类同名静态方法优先于导入方法，调用被遮蔽方法须显式限定类名；冲突源头包括多import、本类定义及依赖多版本；接口静态方法因需接口名限定而天然不冲突。
静态导入本身不制造命名冲突，但它会让已有冲突立刻暴露出来——编译器一旦发现同名静态成员被多处引入，就会报“reference to XXX is ambiguous”。真正要防的不是导入动作，而是名字本身的唯一性设计。
只导入明确、高频、语义清晰的方法
泛化名称（如 get、of、create）极易撞车，尤其在多个工具库共存时。优先选带业务或语义前缀的静态方法：
- 推荐：import static java.util.Objects.requireNonNull; import static com.google.common.base.Preconditions.checkArgument;
- 避免：import static java.util.Collections.*; import static com.google.common.collect.Lists.*;
本类方法名优先于静态导入
如果当前类里定义了同名静态方法，调用时默认走本类实现。这不是错误，而是 Java 的明确规则。但容易让人误以为调用了外部工具方法。
- 想调用被遮蔽的静态导入方法？必须显式用类名限定，比如 Collections.emptyList()；
- 想保持简洁又避免歧义？把本类方法改名，例如把 format(String) 改成 formatWithLocale(String)；
- 构造器或 setter 中参数与静态字段同名？不用 this，直接换参数名（静态上下文不能用 this）。
查清冲突源头不止看 import
报错行只是表象，冲突可能藏在三个地方：
立即学习“Java免费学习笔记（深入）”；
- 多个 import static 引入了不同包里的同名方法（比如两个 StringUtils 的 isBlank）；
- 当前类自己声明了同名静态字段、常量或方法（如 public static final int TIMEOUT = 3000，又导入了 TimeUnit.SECONDS）；
- 依赖传递引入了同一工具库的多个版本（如 commons-lang3 3.12 和 3.14），导致 IDE 实际解析到两个不同类中的同名方法。
接口里的静态方法天生不冲突
多个接口可以定义同名同参的静态方法，不会编译失败。因为它们彼此隔离，调用时必须加接口名限定：
- A.staticMethod() 和 B.staticMethod() 可以共存；
- 静态方法不参与继承链，也不被实现类获得，所以不存在“重写”或覆盖问题；
- 只要调用时写全接口名，就完全可控，无需规避命名重复。
