静态导入仅在频繁调用同一工具类多个静态成员时适用，如单元测试断言或函数式编程；应避免在业务逻辑、领域模型中使用，且优先显式导入单个方法而非通配符。
什么时候该用 static import？
静态导入只在频繁调用同一工具类的多个静态成员时才值得考虑，比如反复写 Objects.requireNonNull()、CollectionUtils.isEmpty() 或 StringUtils.isBlank()。它不是为了“看起来简洁”，而是为了消除重复前缀带来的视觉噪音。如果一个类里只用一两次，硬加 static import 反而让读者更难定位方法来源。
- 真实适用场景：单元测试里大量断言（
assertThat、equalTo、is）、函数式编程中频繁使用Collectors.toList()、Predicate.isEqual() - 不适用场景：业务逻辑主流程、多人协作的领域模型代码、需要明确表达“这是哪个类提供的能力”的地方
- IDE 自动导入默认关掉
static import，是有道理的——它确实提高了理解成本
static import 的两种写法区别在哪？
写法上只有两个选择：import static java.util.Objects.*; 和 import static java.util.Objects.requireNonNull;。前者导入整个类所有静态成员，后者只导一个。
- 通配符（
*）看似省事，但会污染命名空间：如果两个工具类都有isNull()，编译直接报错，而且你可能根本没意识到冲突来自静态导入 - 显式导入单个方法更安全，也更容易被 IDE 管理（比如重命名时只影响一处）
- JDK 9+ 中，模块系统对
static import *没有额外限制，但团队代码规范往往禁止它，理由很实际：grep 查不到谁引入了某个静态方法
为什么有时候写了 static import 却调不了方法？
常见错误不是语法问题，而是作用域和可见性被忽略了：
-
private静态方法不能被导入，哪怕在同一个包里也不行 - 默认（包私有）访问级别的静态方法，只能被同包内类通过
static import调用 - 如果工具类是
final但方法是static，不影响导入；但若方法被default修饰（接口里的），JDK 8+ 才支持导入，且必须是public static - Maven 编译时提示
cannot find symbol，大概率是依赖版本太低，比如用了旧版 Apache Commons Lang，其中StringUtils的某些方法还没加public static修饰
替代方案比 static import 更稳妥？
真要简化调用，多数时候优先考虑这些：
立即学习“Java免费学习笔记（深入）”；
- 直接用 IDE 的静态方法补全：输入
Obj+ Ctrl+Space 就能展开Objects的方法，不比requireNonNull多敲几个键 - 在类顶部加注释说明工具类用途，比如
// Using Objects for null-safety checks，比隐藏导入更利于协作 - Kotlin 用户直接无视这个问题——它的顶层函数天然就是“静态可导入”的，Java 里硬模仿反而得不偿失
- 如果是自定义工具类，可以考虑把常用组合封装成新方法，比如
checkIdNotNull(id)，语义比裸调requireNonNull(id, "id must not be null")更清晰
静态导入不是语法糖，是命名空间操作。用错一次，排查起来比多敲几个点还费时间。
