该用 static import 仅当频繁调用同一类多个静态成员且显著提升可读性时，如单元测试中使用 assertthat、equalto 等；禁用于业务逻辑，避免命名冲突与可追溯性下降。
什么时候该用 static import？
只在频繁调用同一类的多个静态成员（比如 Math.abs、Math.max、Math.PI）且明显提升可读性时才考虑。不是为了“省几个字”，而是消除重复前缀带来的视觉噪音。
常见误用场景：导入整个 StringUtils 或 Collectors 类——结果反而让读者没法一眼看出某个方法来自哪，还容易引发命名冲突。
- 适合：单元测试里大量用
assertThat、equalTo、is等断言工具 - 不适合：业务逻辑中导入
System.out或Arrays.asList - 更安全的做法：优先用 IDE 的静态方法自动补全，而不是靠 import 缩短写法
static import 的写法和常见报错
语法很简单，但错一个字母就编译失败，而且错误提示往往不直观。
正确写法是：import static java.lang.Math.*; 或 import static org.junit.Assert.assertEquals;。注意 static 关键字必须紧挨 import，中间不能换行或加空格。
立即学习“Java免费学习笔记（深入）”；
- 错误现象：
error: package xxx does not exist—— 很可能漏了static，写成了普通import - 错误现象：
error: cannot find symbol—— 检查类路径是否包含该类，比如import static org.mockito.Mockito.when;却没加 mockito 依赖 - 错误现象：两个
static import引入同名方法（如都导入了isNull），编译直接失败，必须显式写出类名调用
和普通 import 的行为差异在哪？
普通 import 只影响类名解析；static import 是把静态成员“拉平”到当前命名空间，相当于在本类里重新声明了一次这些方法/字段。
这意味着：它不改变任何运行时行为、不增加类加载开销、也不影响字节码大小——纯粹是编译期语法糖。
- 性能无差别，别指望它加速
- IDE 重构（如重命名方法）仍能正确识别并更新所有
static import引用 - 但 javadoc 不会自动关联被导入的静态成员，文档生成时需额外配置
为什么团队代码里很少见 static import？
不是它不好，而是协作成本高。新人第一次读到 asList("a", "b") 时，得翻半天才知道这是 Arrays.asList 还是自定义工具类的方法。
尤其当项目用了 Lombok、Guava、Apache Commons 多个工具库后，静态方法同名率很高，join、emptyList、checkNotNull 都可能撞车。
- 建议：只在测试类或极小范围的工具类中启用
- 禁止在 public API 类或 Spring Bean 中使用
- 如果用了，务必在类开头加注释说明导入来源，比如
// static imported from Collectors for stream grouping
真正难的不是怎么写，是怎么让别人不猜——静态导入的简洁性，是以可追溯性为代价的。
