静态导入用于规范常量使用方式，提升简洁性与可读性，仅限高频、语义明确、具全局共识性的常量（如math.pi），禁用通配符，常量类需职责清晰、命名规范，并优先结合枚举使用。
Java 中 static 静态导入不是用来“规范”常量本身的，而是用来规范常量的使用方式——核心是让高频、稳定、无歧义的静态常量在代码中更简洁、更可读，同时避免滥用导致维护困难。
只导入真正高频且语义明确的常量
并非所有 public static final 字段都适合静态导入。关键看它是否具备“全局共识性”：开发者一眼就能认出它代表什么，且几乎不会被重命名或迁移。
- ✅ 推荐导入：Math.PI、TimeUnit.SECONDS、StandardCharsets.UTF_8、DayOfWeek.MONDAY
- ❌ 避免导入：StringUtils.EMPTY、ApiConstants.BASE_URL、Config.TIMEOUT_MS —— 这些要么来自第三方（语义不直观），要么属于项目自定义（易变、作用域模糊）
按需导入，禁用通配符 *
import static xxx.* 看似省事，实则破坏命名空间边界，尤其当多个类导出同名常量（如两个枚举都有 SUCCESS）时，编译器无法分辨来源，IDE 补全也失效。
- 写法正确：import static java.util.concurrent.TimeUnit.SECONDS;
import static java.util.concurrent.TimeUnit.MINUTES; - 写法危险：import static java.util.concurrent.TimeUnit.*;
常量类本身要设计得清晰可维护
静态导入的前提是常量类本身规范。否则再怎么导入，源头就乱了。
- 命名聚焦职责：HttpHeaders、DbConfig、JwtClaims，而非泛泛的 Constants
- 字段命名严格遵循 Java 规范：全大写 + 下划线分隔，如 CONTENT_TYPE_JSON、MAX_RETRY_COUNT
- 避免把运行时可变配置（如从配置中心加载的 host 地址）塞进静态常量类
结合枚举与静态方法提升表达力
枚举天然适合静态导入，因其常量是 public static final 实例；若还定义了静态工具方法（如 fromCode()、valuesSorted()），导入后调用更自然。
- 例如导入 import static com.example.Status.*; 后可直接写 if (status == ACTIVE) { ... }
- 若 Status 定义了 public static Status of(String code)，导入后也能直接调用 of("200")
- 注意：不能选择性导入多个枚举值（如 ACTIVE, PENDING），只能单个导入或通配导入
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
