静态导入不提升逻辑清晰度，仅在调用高频、来源明确、语义无歧义时让逻辑更聚焦；盲目使用会掩盖方法归属、增加理解成本，业务代码中默认禁止，测试与数学计算等特定场景方可按需启用。
静态导入本身不提升逻辑清晰度，它只在特定条件下让逻辑更聚焦——前提是调用高频、来源明确、语义无歧义。盲目使用反而会掩盖方法归属，增加理解成本。
当上下文足够明确时，省略前缀反而突出业务意图
在单元测试中，断言是核心动作，而非“谁提供的断言”。写 assertEquals(expected, actual) 比 Assertions.assertEquals(expected, actual) 更快传达“这里在比值”，而不是“这是哪个类的 assertEquals”。同理，在数学密集型代码里，sin(x) + cos(y) * PI 接近公式原貌，读者注意力自然落在运算关系上，而非类名前缀。
- 测试类中集中使用 JUnit 或 AssertJ 的断言方法（如
assertThat、isNotNull、contains） - 算法类反复调用
Math系列方法（sqrt、log、pow）或常量（PI、E） - 项目内统一的常量类（如
HttpStatus.OK、ApiVersion.V2），导入后直接写OK或V2，状态判断一目了然
只导入真正高频使用的成员，避免命名空间污染
导入 import static java.util.Objects.requireNonNull; 是合理的——判空在构造参数校验中频繁出现；但导入整个 Objects.* 就容易和 StringUtils.isBlank() 或自定义工具类的 isBlank() 冲突，一旦编译报错，开发者得回头排查哪两个类撞了名。显式导入单个成员，既控制范围，也方便 IDE 在重命名或重构时精准联动。
- 每个类最多导入 2–3 个静态成员，超过需在代码审查中说明必要性
- 禁用
import static xxx.*，尤其对第三方库（如 Guava、Apache Commons） - 常量类优先按需导入字段（如
BASE_URL、TIMEOUT_MS），而非通配符
业务逻辑中保留类名，本身就是一种语义提示
System.out.println()、Arrays.asList()、Objects.requireNonNull() 这些调用本就不该高频出现在服务层。保留类名，其实是提醒开发者：“这里触发了 I/O”“这是数组构造”“此处有空值风险”。删掉前缀看似简洁，实则抹掉了设计意图。逻辑清晰度来自对行为边界的诚实表达，而非字符数量的减少。
- Service/Controller/Domain 类默认禁止静态导入，CI 流水线可配置告警
- 若某工具方法被高频使用（如
DateUtils.format()），应审视是否该封装为领域服务，而非靠导入“简化” - 命名冲突时，必须显式写出类名（如
Objects.isNull(x)而非isNull(x)），宁可多打几个字，也不能牺牲可追溯性
配合团队规范，让“省事”不变成“猜谜”
静态导入的价值高度依赖上下文共识。同一个 isEmpty()，在测试类里导入 CollectionAssert.isEmpty() 很自然；但在支付模块里导入 StringUtils.isEmpty() 和 CollectionUtils.isEmpty() 并混用，就极易引发误读。团队应约定：哪些工具类允许导入、哪些场景开放权限、如何命名常量类（如 HttpHeaders 比 Constants 更具指向性）。
- 测试类可宽松，主业务类默认禁止
- 常量类命名需体现领域（如
OrderStatus、PaymentMethod），避免泛化 - IDE 不自动补全静态导入，手动管理时建议按包分组、字母排序，便于快速定位
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
