很多小伙伴熟练写 CRUD 很久，但是始终存在一个疑问：Spring 项目分层到底是谁在干活？接口、实现类、IOC容器各自承担什么角色？数据是如何从数据库流向前端浏览器的？
我们日常开发中经常书写 Service 接口、Service 实现类、Controller、Mapper，看似重复冗余，但每层各司其职。同时很多人混淆了一个核心问题：IOC 只是创建对象、规范依赖，真正执行业务逻辑的到底是谁？
一、先梳理完整项目数据链路（贯穿前端到数据库）
我们先搭建最标准的 SpringBoot 三层架构数据流，这也是所有 Web 项目的核心链路，自上而下完整流转：
前端浏览器 → Controller层 → Service层（业务逻辑） → Mapper层 → 数据库
我们逐层明确每层的核心定位，杜绝概念混淆：
1. Controller 层：桥梁层，只做对接，不写业务
Controller 是前端浏览器与后端服务的唯一交互入口，相当于项目的"大门"。
它的核心工作非常单一：接收前端传递的参数、接收前端请求，调用 Service 层的业务方法，最后将后端处理完成的数据，封装成统一结果返回给前端。
核心特点：Controller 绝不书写任何业务逻辑，只负责调度、传参、响应。
2. Service 层：核心干活层，承载所有业务逻辑
Service 层是整个项目真正的核心工作层，项目所有的规则、判断、计算、事务控制、数据校验等业务逻辑，全部集中在这一层。
日常开发中我们会定义 Service 接口 和 ServiceImpl 实现类：
-
Service 接口：只定义方法范式、定义规范，只声明"有什么功能"，不写任何代码实现，相当于一份功能说明书
-
ServiceImpl 实现类：重写接口方法，书写完整的业务逻辑，是真正执行业务、完成功能的核心类
3. Mapper 层：数据交互层，对接数据库
Mapper 层是 Java 代码与数据库的桥梁。Service 层完成业务逻辑判断后，会调用 Mapper 方法，通过 SQL 语句完成数据库的查询、新增、修改、删除操作，最终将数据库数据传回 Service，再逐层返回给前端。
二、IOC do what？
这是绝大多数开发者的困惑：我们知道 Spring IOC 容器会帮我们创建对象、管理 Bean，那么 IOC 是不是在帮我们执行业务代码？
这里给出最精准、最通俗的标准答案：
IOC 容器不执行任何业务逻辑，它只负责创建、管理所有分层的实体对象；真正干活、执行核心业务逻辑的，永远是 Service 实现类。
1. IOC 的工作本质
我们之前提到：IOC 是在元层面切断代码依赖，剥离对象创建的控制权。
在传统 Java 开发中，我们需要手动 new ServiceImpl() 创建对象，代码耦合度极高；而在 Spring 中，我们无需手动创建对象。
IOC 容器会扫描项目中所有带注解的类（Controller、Service、Mapper），自动将其实例化为 Bean 对象，统一管理生命周期，同时完成依赖注入。
2. 分层视角下 IOC 的作用
Controller 需要调用 Service 的方法，如果没有 IOC，我们需要在 Controller 中手动 new 业务类，代码高度耦合。
而 IOC 容器提前创建好Service 实现类 Bean，自动注入到 Controller 中。
简单来说：
-
Service 接口：制定规范、定义方法模板，约束实现类的功能范围
-
IOC 容器：创建接口对应的实现类对象，作为规范调用的工具
-
Service 实现类：承载所有业务逻辑，是底层唯一真正干活的类
三、完整执行流程复盘
我们结合一次完整的前端请求，来复盘一下 IOC + 分层架构 的全部工作流程：
第一步：项目启动
Spring 启动后，IOC 容器自动扫描全局组件，提前创建 Controller、ServiceImpl、Mapper 的 Bean 对象，统一管理，完成依赖注入，做好随时调用的准备。此时仅仅是创建对象，没有执行任何业务代码。
第二步：前端发起请求
浏览器发送接口请求，请求到达 Controller 层。Controller 作为调度入口，调用已经被 IOC 注入好的 Service 对象方法。
第三步：执行核心业务
被调用的 Service 接口，底层指向对应的 Service 实现类，由实现类中的方法代码完成全部业务逻辑判断、数据处理、事务操作。
第四步：操作数据库
Service 业务逻辑处理完成后，调用 IOC 注入的 Mapper 对象，执行 SQL，完成数据库数据交互。
第五步：数据回流响应前端
数据库数据通过 Mapper 返回至 Service，处理封装后传回 Controller，最终由 Controller 统一封装结果，返回给前端浏览器，形成闭环数据链路。
controller层连接前端浏览器和服务层，服务层用来写业务逻辑，通过业务逻辑借助mapper将数据库的内容链接到controller连接浏览器形成一条完整的数据链，其中核心工作的服务层满是业务逻辑范式接口，它通过ioc创建相关实体类，但只是创建了类和规定了方法范式，具体的方法实现还要借助相关的实体类，ioc容器创建的实体作为规范的调用工具底层核心工作的是实现了serviceImpl中的方法
四、核心概念区分
-
Service 接口：仅定义方法范式、业务规范，只做约束，不干活、不创建对象、无逻辑代码
-
IOC 容器 ：全局对象工厂，只负责 创建对象、解耦、依赖注入、管理生命周期，不执行任何业务逻辑
-
Service 实现类：项目业务核心，唯一执行业务逻辑、完成功能开发的底层载体
-
分层架构：Controller 负责对接调度，Service 负责业务处理，Mapper 负责数据持久化
分清框架和业务的边界，框架永远只是辅助工具。
IOC 解决的是对象创建、代码耦合、分层依赖的结构性问题，让分层架构更加优雅、易于维护；
真正支撑项目功能、完成业务需求的是 Service 实现类业务代码。