Java中依赖关系指类在方法中临时使用另一类对象，用完即弃，不持有其引用；典型写法有方法参数、局部变量和静态调用，核心特征是无成员变量、不管理生命周期。
Java 中的依赖关系，就是“我用你，但不养你”——一个类在某个方法里临时用到另一个类的对象，用完即弃，不持有、不管理生命周期。
依赖关系怎么写？看这三种典型写法
依赖不是靠字段存着，而是靠“当场调用”体现。它最轻量，也最容易被误当成关联或组合。
方法参数：最标准的依赖形式，比如public void send(EmailService service)—— 调用时才传入，类本身没存这个service局部变量：方法内部new出来就用，比如List，list = new ArrayList<>() ArrayList就是当前方法对 JDK 类的临时依赖静态调用：比如Collections.sort(items)，Collections是工具类，没实例化，只借它的静态方法一用
为什么依赖容易被混淆？关键看“有没有字段引用”
很多人把 private EmailService emailService; 也叫依赖，其实那是关联（甚至可能是聚合/组合）。真正的依赖必须满足：没有成员变量、不控制对方生命周期、用完就丢。
- ✅ 依赖：
void process(Order order, PaymentGateway gateway)—— 参数传入，无字段 - ❌ 不是依赖：
private PaymentGateway gateway = new AlipayGateway();—— 这是硬编码关联，耦合已升高 - ⚠️ 注意：Spring 的
@Autowired注入字段，表面像依赖，实际是框架替你做了“解耦后的关联”，不能反推为语言层面的依赖关系
依赖关系在 UML 和 Spring 中的意义完全不同
UML 里的依赖（虚线箭头）强调设计时的弱耦合意图；而 Spring 说的“依赖注入”，其实是把原本硬编码的关联关系外移，让它可配置、可替换。两者语义错位，但目标一致：降低修改成本。
- UML 依赖：画图时标出“这里会用到”，不承诺谁创建、谁销毁
- Spring 依赖：运行时由容器决定给哪个实现，比如测试时注入
MockEmailService，生产用SmtpEmailService - 坑点：过度依赖
@Autowired字段注入，会让类失去无容器环境下的可测试性——构造器注入才是更贴近“依赖”本意的做法
class UserService {
private final NotificationService notifier; // 构造器注入，明确表达“我需要一个通知服务”
public UserService(NotificationService notifier) {
this.notifier = notifier; // 不 new，不 static，不 null 默认值
}
public void register(User user) {
notifier.sendWelcome(user); // 这里才是真正的“使用”，即依赖行为
}
}
真正难的不是识别依赖，而是判断“该不该让它只是依赖”。比如日志对象 Logger，几乎每个类都用，但它既不该被 new，也不该被注入字段——它属于基础设施，应通过 SLF4J 静态获取，这才是符合依赖本质的用法。
