静态导入不增强可维护性，反而因命名冲突、来源不可见、重构断裂等风险削弱它；应严格限制使用范围与数量，优先采用带类名的显式调用。
不能，静态导入本身不增强代码可维护性；它可能在极少数受控场景下提升表达简洁性，但整体上更常削弱可维护性——关键在于是否严格约束使用方式。
命名冲突风险直接破坏编译稳定性
当多个类提供同名静态成员时，静态导入会让编译器无法唯一解析调用。例如：
- 同时导入
java.util.Collections.emptyList()和com.google.common.collect.ImmutableList.of()，再写emptyList()就触发reference to emptyList is ambiguous错误 - 本类定义了
public static String format(String)，又静态导入java.text.MessageFormat.format，调用format("x")即报错
这类问题不会在编码时暴露，往往等到重构或升级依赖后才集中爆发。
来源不可见拖慢理解与协作效率
去掉类前缀后，assertEquals、PI、now() 等调用不再自带上下文。新成员或半年后回看代码的人，需反复翻查 import 区或跳转定义才能确认归属。研究显示，理解含 3 个以上静态导入的类，平均耗时增加 25%。IDE 补全还会列出多个同名方法，选错一个就引入泛型擦除、类型不匹配等隐蔽问题。
重构与升级时隐性断裂更难排查
静态导入把调用和来源强绑定：
- 被导入类删掉某个方法，所有静态引用点无声失效，IDE 很难跨模块精准定位
- 项目拉入不同版本的同一工具库（如 commons-lang3 3.12 和 3.14），类加载顺序不同可能导致运行时
NoSuchMethodError
真正能提升可维护性的做法是克制而非启用
- 单文件静态导入不超过 3 个来源，且禁止同时导入
StringUtils.isEmpty()和CollectionUtils.isEmpty()这类同名方法 - 只显式导入高频、无歧义、语义稳定的成员，如
import static java.util.Objects.requireNonNull;，而非import static java.util.Objects.*; - 测试类可适度放宽（如
Assertions.*），但业务逻辑层坚持带类名调用，或仅导入纯常量（Math.PI、TimeUnit.SECONDS） - 导入块统一放在普通 import 下方，按包路径字母序排列，便于 Code Review 扫描
不复杂但容易忽略
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
