静态导入削弱代码可读性，核心在于来源不可见——方法或常量脱离类名上下文，导致调用点归属模糊、语义锚点缺失、命名冲突加剧、重构成本上升。
静态导入会削弱代码可读性，核心问题在于“来源不可见”——方法或常量脱离了类名上下文，读者无法一眼判断它来自哪个类、属于什么语义范畴。
调用点失去归属线索
写 isBlank("test") 时，没人能立刻知道这是 Apache Commons 的、Guava 的，还是项目自定义工具类的。尤其在混合使用多个工具库的项目里，必须翻查 import 区、全局搜索，甚至点进方法定义才能确认来源。研究显示，理解含 3 个以上静态导入的类，平均多耗时 25%。
- IDE 补全常列出多个同名方法（如
isBlank），选错一个可能引入类型不匹配或行为差异 - 半年后回看自己写的
format("x")，得花时间确认是String.format还是MessageFormat.format - 新人接手时，面对一堆无前缀的静态调用，很难建立清晰的模块边界认知
语义锚点被抹除
方法名本身不携带职责信息。比如 checkState(condition) 看起来只是个校验，但加上 Preconditions.checkState 就明确表达了“这是前置断言，失败应中断流程”。去掉类名后，调用意图变得模糊，容易误用或忽略其设计约束。
-
requireNonNull(obj)和Objects.requireNonNull(obj)在语义上等价，但后者让人一眼识别出这是空值防护机制 - 业务逻辑中写
emptyList()而非Collections.emptyList()，弱化了“这是不可变空集合”的设计本意 - Controller 层直接写
now()，不如LocalDateTime.now()清晰表达时间上下文
命名冲突加剧理解负担
当多个静态导入提供同名成员（如 or、and、of），编译器报错只是表象；更麻烦的是，错误未暴露前，开发者已基于错误假设编写逻辑。
- 同时导入
Stream.of和Optional.ofNullable后，写of(...)可能意外触发泛型擦除，导致运行时类型异常 - 某次升级后，
StringUtils.isBlank行为变更，但因静态导入掩盖了来源，问题延迟到测试阶段才被发现 - 团队若未约定禁用列表（如禁止
Collections.emptyXXX系列），不同成员各自导入，代码风格迅速碎片化
重构与协作成本隐形上升
静态导入让调用和来源强绑定，却隐藏了这种依赖关系。重构时 IDE 很难自动提示哪些地方需要同步调整，协作中也缺乏显式契约。
- 把
ValidationUtils.validate()迁移到新包后，原有静态导入不会自动更新，所有调用点直接编译失败，且无迁移建议 - 通配符导入（
import static xxx.*;）更危险：删掉一个方法，错误可能只在特定分支路径下才暴露 - Code Review 难以快速判断某次导入是否合理，往往只能靠人工经验识别风险
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
