同名静态方法被多个类导入会导致编译期“reference to isNull is ambiguous”错误；本类同名方法优先调用，遮蔽的导入方法需加类名前缀调用；应禁用通配符导入、按需导入具体方法、导入前全局搜索、制定团队禁用列表，并通过IDE提示定位冲突后保留语义更优者或封装薄包装。
冲突根源：同名静态方法被多个类导入
当两个或多个工具类都提供相同名称的静态方法（比如 isNull、join、or），又都被静态导入时，编译器无法判断你调用的是哪一个，就会报错：“reference to isNull is ambiguous”。这不是运行时问题，而是编译期直接拒绝生成字节码。
优先级规则：本类方法永远胜出
如果当前类自己定义了一个与静态导入同名的方法（例如你写了 public static void checkArgument(...)），那么直接写 checkArgument(...) 时，Java 总是调用本类的方法，而不是导入的那个。这属于语言规范行为，无需额外处理。
- 想调用被遮蔽的静态导入方法？必须显式加类名前缀，比如 Preconditions.checkArgument(...)
- 这种遮蔽不报错，但容易引发逻辑误用——表面调用的是校验，实际执行的是你自定义的空实现
规避冲突的实操策略
静态导入本身不解决冲突，关键在导入前的控制和导入后的补救：
- 禁用通配符导入：坚决不用 import static xxx.*;，尤其对 Collections、Mockito、Guava 这类“方法命名泛化”的库
- 按需导入具体方法：只导入真正高频且无歧义的，例如 requireNonNull、isBlank、defaultString
- 导入前全局搜索：在 IDE 中 Ctrl+F 搜索当前类及父类中是否已存在同名方法或变量
- 团队约定禁用列表：比如禁止导入 Collections.emptyList()、Stream.of()、Optional.ofNullable()
发现冲突后的快速修复
一旦编译报错或 IDE 显示红色波浪线，别急着删导入语句：
立即学习“Java免费学习笔记（深入）”；
- 把鼠标悬停在报错方法名上，IDE 会提示它“可能来自 A 类或 B 类”，帮你定位冲突源
- 保留更符合语义的那个导入，另一个改用全限定调用（如 Objects.isNull(x)）
- 若两个都常用，可封装一层薄包装方法，比如 CheckUtils.requireNonZero()，把来源收口
