不用 new 是为了解耦调用方与实现类，避免因类名、参数或路径变更导致的全局修改；依赖注入通过声明依赖、定义创建方式和容器管理实现解耦，需确保类被正确扫描或配置，构造器注入更安全可靠。
为什么不用 new 就能拿到对象
Java 里手动 new UserService() 创建对象，会导致调用方和实现类强耦合。一旦 UserServiceImpl 改名、加参数或换包路径，所有 new 它的地方都得改。依赖注入（DI）的核心思路是：把对象的创建和使用分开——谁用对象，不负责造对象；谁造对象，不关心谁在用。
实际落地靠三件事：声明依赖（比如用 @Autowired）、描述对象怎么造（比如用 @Component 或 @Bean）、交由容器统一管理生命周期。没有 Spring 容器，光写注解没用；没有明确的装配规则，容器也不知道该塞哪个实例。
@Autowired 找不到 Bean 的常见原因
@Autowired 报错 “No qualifying bean of type 'xxx' available”，不是注解写错了，而是容器根本没加载到目标类。排查顺序如下：
- 目标类是否加了
@Component、@Service、@Repository等构造型注解，且该类在 Spring 扫描路径下（检查@SpringBootApplication所在包是否包含它） - 如果是手动配置的
@Bean方法，确认它所在的@Configuration类已被组件扫描或显式导入 - 接口有多个实现类时，仅用
@Autowired会失败，必须配合@Qualifier("beanName")或@Primary - 测试类中未启用 Spring 上下文（比如忘了加
@ExtendWith(SpringExtension.class)和@ContextConfiguration）
构造器注入比字段注入更可靠
字段注入（直接在属性上写 @Autowired）写起来快，但隐藏了依赖关系，且无法在构造后校验必填依赖是否为空。构造器注入强制传入依赖，天然支持 final 修饰，也便于单元测试时手动传参。
立即学习“Java免费学习笔记（深入）”；
public class UserController {
private final UserService userService;
// 构造器注入：Spring 5.3+ 支持无 @Autowired 自动装配
public UserController(UserService userService) {
this.userService = userService;
}
}
注意：如果类有多个构造器，必须给主构造器加 @Autowired（Spring 4.x）或确保它是唯一非空参构造器（Spring 5.3+）。否则容器可能选错构造器，抛出 BeanCreationException。
自己写简易 DI 容器也能解耦，但别真用在生产环境
理解原理可以手写一个极简版：用 ConcurrentHashMap 存实例，扫描类路径下带自定义 @MyComponent 的类，反射调用无参构造器创建对象并缓存。但真实项目中，你绕不开以下问题：
- 循环依赖（A 依赖 B，B 依赖 A）——Spring 用三级缓存解决，自己实现极易死锁或空指针
- 代理增强（如
@Transactional）需要动态字节码织入，JDK Proxy 或 CGLIB 不是简单几行能搞定的 -
作用域管理（
@Scope("prototype")每次返回新实例，@Scope("singleton")全局唯一）涉及并发安全和销毁回调 - 条件化装配（
@ConditionalOnMissingBean）需要解析注解元数据并介入 Bean 定义注册流程
所以，解耦设计的关键不在“要不要用 DI”，而在于**让哪些类进容器、哪些类保持手工控制、哪些依赖必须不可变**。过度容器化反而增加启动耗时和调试成本。
