通配符静态导入（如import static java.util.collections.*;）虽简化书写，但易引发命名冲突、来源不可见和重构风险，仅推荐在单元测试等可控场景谨慎使用。
Java 中静态导入配合通配符（*）确实能省去重复写类名的麻烦，但实际用起来得格外小心——它不是“一键简化”，而是把便利和风险一起打包给了你。
通配符静态导入的写法与限制
语法很简单：import static java.lang.Math.*; 就能把 Math 类所有 public static 成员（方法如 sqrt、abs，常量如 PI、E）直接拉进当前作用域。但要注意：
- 只能导入 public 的静态成员，包级或
protected的不会被识别； - 不能导入实例方法、构造器、普通字段；
- 静态内部类、枚举常量（如
DayOfWeek.MONDAY）也能通过通配符导入，前提是它们是 public static 的。
为什么多数场景不推荐通配符导入
表面上看，import static java.util.Collections.*; 之后直接写 emptyList() 很清爽，但隐患藏在细节里：
- 多个类导出同名方法（比如
Objects.requireNonNull和Preconditions.checkNotNull），IDE 在重构或跳转时容易混淆来源； - 调用
max(a, b)时，你无法一眼判断它是来自Math.max还是Integer.max，甚至是你自己写的工具方法； - 项目编译或 IDE 索引出问题时，通配导入可能漏掉部分引用，导致“找不到符号”却查不出源头。
哪些地方可以谨慎放宽限制
通配符不是原罪，关键看上下文是否可控：
-
单元测试类 是最常见且被广泛接受的例外。JUnit 5 的断言（
assertEquals、assertTrue）常统一用import static org.junit.jupiter.api.Assertions.*;，因为测试代码本身语义聚焦、生命周期短、命名冲突概率低； - 小型工具脚本或演示代码，对可维护性要求不高，追求简洁表达时也可临时使用；
- 团队明确约定某类工具（如自定义的
StringUtils）只提供无歧义的静态方法，并在规范中允许其通配导入。
比通配符更稳妥的替代方案
想兼顾简洁与清晰，优先考虑这些做法：
- 按需精确导入：
import static java.lang.Math.PI;和import static java.lang.Math.sqrt;，既省字母又保可读； - IDE 辅助：开启 “Show import path on hover”，鼠标悬停就能看到方法真实出处；
- 用静态方法引用替代直接调用，例如
Function<double double> f = Math::sqrt;</double>，逻辑更显式； - 封装一层薄薄的工具类，比如
Calc.sq(double x)包装Math.sqrt(x)，把静态导入的决策收归一处。
通配符静态导入像一把快刀，切得利落，但也容易误伤。真正影响代码质量的，从来不是少敲几个字符，而是别人（包括未来的你）能不能一眼看懂那行 min(a, b) 到底是谁家的孩子。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
