静态导入适用于高频、语义明确的场景，如单元测试断言、数学计算、工具类方法调用；应显式导入具体成员，禁用通配符，避免命名冲突与可读性下降。
静态导入（static import）能让代码更简洁，尤其在频繁调用工具类的静态方法或常量时。但它不是“万能简化器”，用错反而降低可读性。关键在于：只对真正高频、语义明确的静态成员使用，避免通配符导入。
什么时候该用 static import？
适合以下场景：
- 大量调用同一工具类的静态方法，比如
java.util.Objects的requireNonNull、equals - 频繁使用数学常量或函数，如
Math.PI、Math.sqrt - 测试中反复使用
Assertions或Mockito的静态断言/模拟方法（如assertThat、when）
怎么写才清晰不混乱？
推荐显式导入具体成员，而不是用 .*：
// ✅ 推荐：明确知道导入了什么import static java.lang.Math.PI;import static java.lang.Math.sqrt;import static java.util.Objects.requireNonNull;
// ❌ 不推荐：模糊来源，易冲突、难维护import static java.lang.Math.*;
注意命名冲突和可读性陷阱
如果两个静态导入的成员名相同（比如都导入了 Assertions.assertEquals 和 CustomUtils.assertEquals），编译会报错。此时必须：
立即学习“Java免费学习笔记（深入）”；
- 去掉其中一个静态导入，改用类名调用（
CustomUtils.assertEquals(...)） - 或保留一个，另一个始终用全限定名
另外，过度使用会让读者难以判断某个方法是实例方法还是静态方法。例如看到 isBlank(str)，若没导入提示，可能误以为是 String 的实例方法（实际是 StringUtils.isBlank）。
替代方案有时更合适
静态导入不是唯一简化路径：
- IDE 自动补全 + 快捷键（如 IntelliJ 的
Ctrl+Space）已极大减少输入成本 - 提取局部变量或私有工具方法，比全局静态导入更可控
- 使用 record 或 sealed class 配合静态工厂方法，让构造逻辑更内聚
