静态导入不减少依赖，仅简化调用；精简引用需包结构设计与静态导入协同：按业务域分包、分层职责、统一工具类位置，并严格控制导入范围与命名冲突。
静态导入本身不减少项目依赖，它只简化代码中对已有静态成员的调用写法。真正精简引用依赖，靠的是包结构设计与静态导入的协同配合——前者控制“谁能被谁用”，后者优化“怎么用得清楚又高效”。
包结构先行：划定模块边界，自然收缩依赖面
依赖膨胀往往源于包组织混乱。一个清晰分层的包结构，能让静态导入只在必要范围内生效，避免跨域滥用：
- 按业务域划分顶层子包（如 order、payment、user），彼此禁止直接 import，强制通过 API 接口通信
- 每个业务域内统一职责分层，例如 service、repository、dto，避免把工具方法散落在各处
- 通用工具类（如 DateUtils、JsonUtils）统一放在 com.example.shared.util 下，供多模块按需引用，而非各自复制
- 构建阶段用 maven-enforcer-plugin 检查非法跨域 import，让静态导入只能作用于已批准的依赖路径内
静态导入只用于高频、无歧义的稳定成员
不是所有 static 成员都适合导入。精简引用的关键是“少而准”，而非“多而省事”：
- 优先导入 JDK 中语义明确、几乎不会变更的常量或方法，例如 TimeUnit.SECONDS、StandardCharsets.UTF_8、Math.PI
- 自定义常量类（如 ApiConstants）只按需导入具体字段，例如 import static com.example.ApiConstants.BASE_URL;，拒绝 .* 通配
- 测试类中可适度使用 JUnit 的断言工具（如 assertThat、is），但业务类中禁用第三方工具类（如 StringUtils.isEmpty）的静态导入
- 若某 Service 类频繁静态导入另一个模块的工具方法，说明职责可能错位——应考虑将逻辑下沉，或提取为共享服务
避免命名污染，保持来源可追溯
静态导入一旦滥用，会让代码变成“黑盒调用”。控制引用复杂度，核心是让每个符号都能一眼定位来源：
- 禁止两个不同类中同名静态方法同时被导入（如 isNull 来自 Assert 和 Objects），否则编译失败
- IDE 虽能高亮显示导入来源，但团队协作时建议在首次使用处加简短注释，例如 // from com.example.validation.ValidationRules
- 不把 System.out.println 或 Arrays.asList 静态导入进业务类——这掩盖副作用，也违背日志/集合规范
- 用 IDE 的自动补全替代盲目导入：输入 toStri 后选择 Integer.toHexString，比先写 import static 再调用更安全、更可控
重构友好性：静态导入不影响运行时，但影响可维护性
它只是编译期语法糖，不改变字节码、不增加类加载开销。但对人而言，它是双刃剑：
- 重命名一个静态方法时，IDE 会自动更新所有静态导入的引用，这点很可靠
- 但 javadoc 默认不关联被导入的成员，生成文档时需额外配置 -link 参数指向源码
- 新人阅读代码时，看到 SUCCESS_CODE 不知来自哪个 Constants 类——所以内部工具类的静态字段，除非全项目共识，否则不导入
- Spring Bean、Controller、DTO 等 public API 层禁止使用静态导入，确保接口契约清晰、可测、可演进
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
