static import 能简化频繁使用的静态成员调用，提升代码简洁性，但须以不损害可读性和维护性为前提；应显式导入必要成员，避免通配符，慎用于仅调用一两次或易引发命名冲突的场景。
Java 中的 static import 可以让代码更简洁，尤其在频繁使用某个类的静态成员时。但它不是“越用越好”，关键在于是否提升可读性与维护性。
导入静态常量：减少重复类名前缀
当多个地方引用同一组常量（如 HTTP 状态码、配置键名），用 import static 能避免反复写 HttpServletResponse.SC_OK 这类冗长表达式。
- 写法示例：
import static javax.servlet.http.HttpServletResponse.*; - 之后可直接写
SC_OK、SC_NOT_FOUND，语义清晰且省字符 - 注意：不要导入
*所有常量，容易引发命名冲突；建议显式列出需要的几个，例如：import static java.time.temporal.ChronoUnit.DAYS; import static java.time.temporal.ChronoUnit.HOURS;
导入静态方法：让工具类调用更自然
像 Objects.requireNonNull()、Collectors.toList() 这类高频静态方法，导入后可直接调用，接近“内置函数”的书写体验。
- 常见导入：
import static java.util.Objects.requireNonNull;→ 后续写requireNonNull(str) -
import static java.util.stream.Collectors.*;→ 支持toList()、toSet()等直接使用 - 风险提示：若多个类含同名静态方法（如两个工具类都有
format()），导入后编译会报错，必须显式指定类名调用
何时不该用 static import
简化不能以牺牲可读性为代价。以下情况建议放弃或谨慎使用：
立即学习“Java免费学习笔记（深入）”；
- 仅使用一两次静态成员，加上类名反而更清楚来源（比如
Math.abs(x)比单独abs(x)更易理解） - 团队规范禁止通配符导入（
import static xxx.*），因其隐藏了实际依赖，不利于代码审查和重构 - 测试类中常用
import static org.junit.jupiter.api.Assertions.*;，这是合理场景；但业务逻辑里大面积导入，会让新成员难定位方法归属
替代思路：静态导入 ≠ 唯一简化方式
如果发现某类静态成员被大量引用，可能说明设计上存在改进空间：
- 考虑封装成实例方法，通过依赖注入传递（如把
DateUtils.format(...)改为dateFormatter.format(...)） - 对配置常量，可用枚举替代接口或类定义的
public static final字段，增强类型安全和 IDE 提示 - 部分现代框架（如 Spring Boot）已提供自动装配的工具 Bean，比静态方法更利于 mock 和测试
