静态导入是有限边界的语法糖，非代码瘦身捷径；应避免通配导入，仅导入高频无歧义的单个方法，业务代码慎用，测试类可适度使用，须防范命名冲突、语义丢失与可读性下降。
静态导入不是代码瘦身的捷径，而是有边界的语法糖。用得不当，反而让方法来源模糊、冲突频发、新人难懂。
通配导入是最大误区
像 import static org.apache.commons.lang3.StringUtils.*; 这类写法看似省事，实则埋下隐患：IDE无法精准提示来源，编译器不报错但运行时可能调用错版本，团队协作中更难追溯逻辑出处。真正该做的，是只拉入高频、无歧义的单个方法：
- 推荐：import static org.apache.commons.lang3.StringUtils.isBlank;
- 推荐：import static java.util.Objects.requireNonNull;
- 避免：import static java.util.Collections.*;（emptyList、singletonList易与Lombok或自定义工具类冲突）
业务代码中慎用静态导入
测试类里大量使用 assertThat、equals、is 等断言方法，合理且常见；但业务逻辑中导入 System.out.println、Arrays.asList 或 Preconditions.checkState，就属于职责错位。这些调用本应体现明确上下文——比如 Preconditions.checkState 明确表达了“这是前置校验”，而直接写 checkState 就丢失了语义锚点。
- 校验逻辑集中处可适度导入 requireNonNull、checkArgument
- 工具类封装层内部可导入少量高频方法，但对外暴露的 public 方法禁止静态导入调用
- Spring Bean 类、Controller、Service 层原则上不启用静态导入
命名冲突比想象中更常见
不是只有同名方法才会撞车。当两个静态导入都含 isNull、join、or、and 时，编译器直接报错：“reference to isNull is ambiguous”。更隐蔽的问题是：某次升级 Guava 后，其 Preconditions.checkNotNull 与自定义的 CheckUtils.checkNotNull 行为不一致，而静态导入掩盖了这个差异。
- 导入前先搜索当前类及父类中是否已存在同名方法或变量
- 团队应约定禁用列表，例如禁止导入 Collections.emptyXXX 系列、Stream.of、Optional.ofNullable
- CI 流程中加入检查规则：禁止 import static .*; 语句出现在非测试包路径下
可读性优先于简洁性
一行代码少打几个字，换来的是别人读三次才明白 isBlank 来自哪个库。尤其在混合使用 Apache Commons、Guava、Spring Utils 的项目里，“一眼定位来源”比“少敲两个点”重要得多。
- 新人接手时，看到 asList("a", "b") 第一反应是 Arrays 还是自定义 AsListUtils？静态导入让这个问题没有答案
- 调试时断点进不去？因为 IDE 跳转可能指向错误的同名静态方法
- Javadoc 不自动关联被导入的静态成员，文档生成需额外配置，否则 API 文档缺失关键说明
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
