ioc 是思想目标，di 是其实现手段；ioc 将对象创建与管理权从代码移交容器，di 通过构造器、setter 或字段注入完成依赖装配，实现解耦、易测与灵活扩展。
Spring 的 DI（依赖注入）和 IOC（控制反转）不是两个并列概念，而是一体两面：IOC 是目标和思想，DI 是达成这个目标最主流、最实用的手段。
IOC 解决的是“谁来创建和管理对象”的问题
传统写法里，类自己 new 依赖对象，比如：
UserService userService = new UserService(new UserDao());
这带来三个硬伤：类和实现强耦合、替换实现要改代码、测试时无法注入 Mock 对象。IOC 的核心就是把“创建谁、怎么创建、什么时候销毁”这些事，从你的业务类里拿走，交给 Spring 容器统一接管。你只管声明“我需要什么”，容器负责“把合适的对象送过来”。控制权从程序员手里，反转到了容器手上。
Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...
DI 是 IOC 在代码层面的具体落地方式
容器不会猜你需要什么，它靠明确的“注入点”来完成装配。Spring 主要支持三种注入形式：
- 构造器注入：在创建对象时通过构造参数传入依赖，天然保证不可变性和必填依赖，推荐作为首选
- Setter 注入：通过 public setter 方法赋值，适合可选依赖或后期动态修改场景
- 字段注入：用 @Autowired 直接标记私有字段，写法最简但破坏封装、难以单元测试，不建议在新项目中使用
它们共同带来真实开发价值
解耦不是空话。比如订单服务要发通知，接口 Notifier 下有 EmailNotifier、SmsNotifier、PushNotifier 多个实现。用 DI 后，只需在配置中切换 bean 实现类，OrderService 代码一行不动；测试时可轻松注入 MockNotifier 验证逻辑；上线后还能按环境配置不同通知策略。对象之间不再“你中有我、我中有你”，而是通过容器协调的松散协作。
别被术语吓住，本质就是分工升级
就像公司里项目经理不再亲自招聘、培训、发工资，而是对接 HR 部门提需求；HR 统一筛选、入职、管理、考核。项目经理专注项目交付，HR 专注人才运营。IOC 容器就是这个 HR 部门，DI 就是项目经理提需求、HR 给人的过程。代码因此变得更专注、更稳定、更容易演进。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
