静态导入应精准克制，只导入高频无歧义的静态成员（如requirenonnull、isblank、pi），禁止通配符导入，显式声明每个成员，并纳入code review与ci规则严格管控。
静态导入本身不决定代码质量，真正影响质量的是怎么选、怎么导、怎么用。关键不是“要不要用”，而是“哪些值得导、导多少、谁来把关”。
只导高频、无歧义的静态成员
导入的目标是减少冗余，不是消灭类名。优先考虑那些调用频繁、语义自明、几乎不会重名的方法或常量。
-
推荐导入：如
requireNonNull、isBlank、checkArgument、PI、abs——这些名字本身已说明用途，去掉前缀后依然可读 -
避免导入：如
emptyList、format、toString——多个工具类都提供同名方法，容易调错或编译失败 - 一个方法是否适合静态导入，就看把它单独写在代码里时，别人能不能立刻猜出它来自哪个类、干啥用
禁用通配符导入
import static xxx.*; 看似省事，实则埋雷。它让 IDE 难以精准提示，也让维护者无法快速定位来源。
- 所有静态导入必须显式写出成员名，例如
import static java.util.Objects.requireNonNull; - 禁止任何形式的
.*静态导入，无论在测试类还是业务类中 - CI 流水线可配置 Checkstyle 或 SonarQube 规则，自动拦截通配静态导入
导入顺序与组织规范
导入不是杂货堆，而是有逻辑的声明区。清晰的顺序能降低阅读成本，也方便自动化检查。
- 静态导入必须放在所有普通
import之前 - 同类静态导入按包路径分组（如先 JDK 的
java.util.Objects，再 Apache Commons，再 Guava） - 同一包下的多个静态导入，按字母顺序排列，便于比对和维护
纳入 Code Review 必查项
静态导入容易被忽略，但恰恰是审查中最该盯住的细节之一。它不该由个人习惯决定，而应成为团队共识。
- PR 中出现新静态导入时，Reviewer 需确认：是否高频使用？是否命名唯一？是否已存在同名本地方法？
- 鼓励在 PR 描述中说明导入理由，例如“为统一参数校验风格，导入
requireNonNull和checkArgument” - 定期扫描存量代码，清理低频或已废弃的静态导入，避免“历史遗留污染”
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
