Spring Boot用户CRUD实战：三层架构落地与代码详解

搞懂Spring Boot用户增删查改，三层设计模式到底怎么落地？这是很多初学后端的朋友最纠结的一道坎。网上讲CRUD的教程一抓一大把，但要么只贴代码不讲为什么，要么绕来绕去把简单事情复杂化。我这个项目很简单，就是一个基于Spring Boot的用户增删查改，核心是用三层设计模式把代码结构理清楚，让新手不只把功能跑起来，还能搞明白每个文件该放哪、每层之间怎么协作。如果你正在做课程设计、准备毕设，或者刚学完Spring Boot基础想找个完整实战练手，这篇文章应该能给你一个可以直接照着抄、也看得懂为什么这么写的参考。

1. 三层设计模式到底在解决什么问题

1.1 一个写死所有代码的Controller会怎么样

很多新手第一天学Spring Boot，习惯性把所有逻辑都塞进Controller里：接收参数、校验数据、操作数据库、处理异常、拼返回结果，全堆在一个方法里。别笑，我见过不少"毕设代码"就是这么干的。一个简单的用户列表接口里，既有数据库查询又有一堆业务判断，还混着各种日志输出和结果封装。

这样写有个致命问题，最开始功能少的时候确实很快，但随着需求增加，Controller越来越胖，改一个查询条件都要在这个几百行的方法里找半天。更麻烦的是复用，假如注册和后台新建用户都要校验同一个规则，你只能复制粘贴同一段校验代码，改一处忘另一处，时间久了就变成万金油项目，谁也看不懂谁也不敢动。

这就是三层设计模式要解决的痛点。它本质上是一种"关注点分离"的思路，把一次请求的处理过程按职责切成几段，让每一层只关心自己的事，层与层之间通过接口通信。代码变得像流水线一样，每一站负责一个环节，出问题也更容易定位。

1.2 Controller、Service、DAO各自到底管什么

我用一个生活化的例子来类比三层架构。你去餐厅吃饭，进门跟服务员点菜，服务员把单子传给后厨，后厨做好菜再由服务员端上来。这个场景里，服务员就是Controller层，后厨就是Service层，而仓库里的食材供应商就是DAO层。

Controller（表现层）只负责跟"客人"打交道：接收前端传过来的参数，把参数整理好交给Service，等Service处理完再把结果封装成前端需要的格式返回出去。它不应该知道数据存在哪张表里，也不应该去写SQL。

Service（业务逻辑层）是整个系统的核心大脑，负责处理业务规则：校验用户名是否重复、密码要不要加密、删除前要不要检查关联数据。它不关心前端传的是JSON还是表单，只专注于"这个业务该怎么做"。

DAO（数据访问层）负责跟数据库打交道，你执行SQL、映射结果集、处理数据库连接事务，统统在这一层完成。它不知道业务规则长什么样，只负责最底层的增删查改。

这三层各司其职，依赖方向是自上而下的：Controller依赖Service，Service依赖DAO。反过来不行，Service不能主动去找Controller要东西，DAO也不能向上调用Service。

1.3 Spring Boot里三层是怎么"粘"起来的

Spring Boot能把这套架构用得很舒服，靠的是依赖注入和控制反转。你在Controller里声明一个Service接口，Spring在启动的时候会自动帮你创建它的实现类并注入进来；Service里声明DAO接口同理。开发者根本不用手动new对象，只管定义接口和实现。

我用三层去编码时，通常的包结构长这样：

com.example.userdemo ├── controller │ └── UserController.java ├── service │ ├── UserService.java │ └── impl │ └── UserServiceImpl.java ├── mapper │ └── UserMapper.java ├── entity │ └── User.java └── config └── ...（其他配置）

看到这里你可能会问，为什么Service要先定义接口再写一个impl实现类，直接写一个类不行吗？我早期也觉得多此一举，但后来在项目里发现，接口的好处是能解耦实现细节。万一以后要换实现方案，或者做单元测试时用模拟对象替换真实Service，接口能让你在不改Controller代码的前提下完成替换。虽然单用户CRUD确实看不出太大优势，但从一开始养成这个习惯，后面做复杂项目就不用来回重构。

2. 用户管理模块的整体设计思路

2.1 从增删查改反推需求场景

用户增删查改听起来很简单，但我们得先想清楚，这四个操作对应的真实业务场景是什么。这样写代码的时候才有方向感，不是机械地复制模板。

• 新增用户：常见的注册、后台管理员创建账号。需要考虑用户名是否重复、邮箱格式是否正确、密码是否需要加密存储。
• 查询用户列表：后台管理系统的用户管理页面，一般需要分页展示，可能还要支持按用户名模糊搜索。
• 查询用户详情：点击某条记录查看完整信息，或者编辑时回显数据。
• 修改用户：更新用户的基本资料，可能是用户自己改昵称头像，也可能是管理员重置密码、冻结账号。
• 删除用户：这里就有讲究了，是真的从数据库DELETE掉，还是用逻辑删除？我后面会详细说，先埋个伏笔。

做这个项目的时候，我把需求范围控制在"最小可用"的状态，不追求一步到位的权限系统、日志审计，先把CRUD链路跑通，把三层结构理清楚，再逐步扩展。这对新手很关键，别一上来就想搞个大而全的系统，学不到东西还容易把自己搞崩。

2.2 数据库表设计：用户表需要哪些字段

用户表的字段设计直接决定了后面代码的复杂程度。我见过不少新手把表设计得特别复杂，用户名、密码、手机号、邮箱、性别、头像、兴趣爱好、个人简介，恨不得把所有属性都塞进去，结果前端页面根本用不上，还白白增加代码量。

我这张用户表保持了最小且必要的字段，但把该考虑的技术细节都覆盖到了：

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID', `username` varchar(50) NOT NULL COMMENT '用户名', `password` varchar(100) NOT NULL COMMENT '密码', `email` varchar(100) DEFAULT NULL COMMENT '邮箱', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：1启用，0禁用', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

几个设计要点值得说道说道。主键用自增的bigint，对单机小项目来说最简单可靠，不需要额外处理。用户名加UNIQUE唯一约束，从数据库层面兜底防止重复，即使代码层校验漏了也能挡住。密码字段长度留到100，因为BCrypt加密后的字符串有60位，varchar(50)显然不够。create_time和update_time都用数据库默认值来维护，省得在Java代码里每个地方手动set当前时间。

2.3 RESTful风格接口清单设计

三层模式配合RESTful风格，能让接口变得特别规整。用户模块我设计了以下一组接口，一看就知道对应的是什么操作：

RESTful的核心思想是把操作对象当成资源，用HTTP方法表示动作。POST代表新增，DELETE代表删除，PUT代表修改，GET代表查询。这样从路由到方法非常直观，前端对接的时候也少很多沟通成本。

这些接口的定义有个小细节，新增和修改我都用了一个不同的路径语义，但前端传参会有差异。新增时ID为空，因为数据库自增；修改时必须有ID，否则不知道更新哪条记录。你们看这组接口就会发现，其实查询用户详情和分页查询是两个接口，一个服务于"单条记录展示/编辑回显"，一个服务于"列表页面/搜索场景"。

2.4 统一返回结构：为什么每个接口都包一层Result

如果让Controller直接返回User对象，前端拿到数据的格式倒是省事，但遇到异常、参数校验失败等场景时，前端就完全拿不到统一的错误信息了。所以我在项目里定义了一个通用的Result类，所有的接口都返回这个结构。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("操作成功"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

这样做的好处，前端只需要根据code先判断请求成功还是失败，成功再取data里的业务数据，失败则直接用message弹出错误提示。代码层面也能统一处理异常，不用在每个Controller方法里疯狂try-catch，这个在后面的异常处理部分我会详细展开。

3. 核心代码实现与实操细节

3.1 项目初始化：脚手架选择与依赖配置

我创建这个项目用的Spring Initializr，网址是 start.spring.io。这里有个重点提醒，如果你用IDEA 2026这种比较新的版本，进去之后Spring Initializr默认生成的Spring Boot版本很可能是3.x。如果你是学习阶段，建议选择Spring Boot 2.7.x，因为这个版本的资料最多，网上踩坑的解决方案最全，而且很多旧教程里的javax包名在3.x里被换成了jakarta，照着抄会直接编译报错。

我用的依赖组合如下：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.2</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency>

最核心的依赖就这几个。spring-boot-starter-web提供了Spring MVC和内置Tomcat，mybatis-spring-boot-starter帮我们整合MyBatis和Spring Boot，MySQL驱动负责数据库连接，Lombok简化实体类的getter/setter。暂时不需要引入Thymeleaf，因为我把前端页面简化成纯接口模式，用Postman或者浏览器直接测试就行。

3.2 application.yml配置：数据源和MyBatis的关键参数

配置文件里的很多参数都是有讲究的，不能只照着抄。我这份配置是长期踩坑后稳定下来的：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/user_demo?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: root mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.userdemo.entity configuration: map-underscore-to-camel-case: true

这里要重点说明三个配置项的含义。第一个是url里的characterEncoding=utf8，如果不加这个参数，插入中文数据就会变成问号乱码，这个问题我当年排查了好几个小时。第二个是serverTimezone=Asia/Shanghai，如果不指定时区，MySQL 8.x会报一个关于server timezone的错误。第三个是map-underscore-to-camel-case，这个必须设置为true，它能自动把数据库的create_time字段映射成Java实体里的createTime属性，否则你查出来的数据里带下划线的字段全部是null。

3.3 实体类与Mapper层：用注解还是XML

实体类我用Lombok来简化，这是最基础也最实用的操作：

@Data public class User { private Long id; private String username; private String password; private String email; private String phone; private Integer status; private LocalDateTime createTime; private LocalDateTime updateTime; }

@Data注解自动生成所有属性的getter、setter、toString方法，这是成年人的偷懒，省得写几百行样板代码。注意createTime和updateTime用的是LocalDateTime，这是Java 8引入的时间类型，配合MySQL的datetime字段非常方便，返回前端时也能直接序列化成字符串。

Mapper接口和XML文件，我这里展示一个典型的写法。接口定义：

@Mapper public interface UserMapper { int insert(User user); int deleteById(Long id); int update(User user); User selectById(Long id); List<User> selectPage(@Param("offset") int offset, @Param("size") int size); long count(); }

对应的XML在resources/mapper/UserMapper.xml里：

<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd"> <mapper namespace="com.example.userdemo.mapper.UserMapper"> <resultMap id="userResultMap" type="com.example.userdemo.entity.User"> <id property="id" column="id"/> <result property="username" column="username"/> <result property="password" column="password"/> <result property="email" column="email"/> <result property="phone" column="phone"/> <result property="status" column="status"/> <result property="createTime" column="create_time"/> <result property="updateTime" column="update_time"/> </resultMap> <select id="selectById" parameterType="long" resultMap="userResultMap"> SELECT id, username, password, email, phone, status, create_time, update_time FROM sys_user WHERE id = #{id} </select> <insert id="insert" parameterType="com.example.userdemo.entity.User" useGeneratedKeys="true" keyProperty="id"> INSERT INTO sys_user (username, password, email, phone, status, create_time, update_time) VALUES (#{username}, #{password}, #{email}, #{phone}, #{status}, NOW(), NOW()) </insert> <update id="update" parameterType="com.example.userdemo.entity.User"> UPDATE sys_user SET username = #{username}, email = #{email}, phone = #{phone}, status = #{status} WHERE id = #{id} </update> <delete id="deleteById" parameterType="long"> DELETE FROM sys_user WHERE id = #{id} </delete> <select id="selectPage" resultMap="userResultMap"> SELECT id, username, password, email, phone, status, create_time, update_time FROM sys_user ORDER BY id DESC LIMIT #{offset}, #{size} </select> <select id="count" resultType="long"> SELECT COUNT(*) FROM sys_user </select> </mapper>

为什么不直接在Mapper接口里用注解写SQL，而是要搞个XML文件？我的经验是，简单查询用注解确实方便，但一旦SQL变复杂，动态SQL判断多了，注解会把Java代码弄得乱七八糟。XML支持动态SQL的 、 、 等标签，维护起来更清晰，而且不用改动Java代码就能调整SQL。做项目不是炫技，选可维护性更好的方案才是正路。

3.4 Service层：事务、业务校验、密码加密

Service层是三层架构里内容最多的一层，这恰恰是很多新手忽略的。很多人的Service就是把Mapper方法直接透传一遍，这叫"形同虚设的中间层"。既然叫业务逻辑层，就要真正承担业务决策。

先看Service接口：

public interface UserService { void addUser(User user); void updateUser(User user); void deleteUser(Long id); User getUserById(Long id); PageResult<User> getUserPage(int pageNum, int pageSize); }

再看实现类，重点看addUser方法里的业务逻辑：

@Service public class UserServiceImpl implements UserService { @Autowired private UserMapper userMapper; @Override @Transactional public void addUser(User user) { // 业务校验：用户名不能为空 if (user.getUsername() == null || user.getUsername().trim().isEmpty()) { throw new RuntimeException("用户名不能为空"); } // 业务校验：用户名不能重复 User existingUser = userMapper.selectByUsername(user.getUsername()); if (existingUser != null) { throw new RuntimeException("用户名已存在"); } // 密码加密存储 String encodedPwd = new BCryptPasswordEncoder().encode(user.getPassword()); user.setPassword(encodedPwd); userMapper.insert(user); } }

这个方法的业务逻辑包含三层判断。第一层是参数的基本合法性校验，虽然Controller也能做，但更规范的是在Service做，因为Service是唯一被多个调用方共享的入口，校验逻辑放在业务层才能保证任何入口进来的数据都经过检查。第二层是查重，通过用户名去数据库查一次，存在就抛异常。第三层是密码加密，这是安全底线，绝对不允许明文存数据库，万一数据库泄露，用户密码等于直接暴露。

更新用户的方法我设计了只更新部分字段，避免把没有传来的字段覆盖成null。这个在真实项目中很重要，用户在编辑页只改了手机号，结果邮箱字段没传到后端，如果UPDATE语句把所有字段都更新一遍，没传的字段就会被置为NULL。所以XML里我只更新那几个明确会传的字段，这也是为什么update方法没有更新密码，密码修改通常有单独的安全方案。

3.5 Controller层：参数接收、分页、统一返回

Controller层的代码是最简单的，因为它只做编排。但简单归简单，有几个细节值得写清楚。

@RestController @RequestMapping("/api/user") public class UserController { @Autowired private UserService userService; @PostMapping public Result<Void> addUser(@RequestBody User user) { userService.addUser(user); return Result.success(null); } @DeleteMapping("/{id}") public Result<Void> deleteUser(@PathVariable Long id) { userService.deleteUser(id); return Result.success(null); } @PutMapping public Result<Void> updateUser(@RequestBody User user) { userService.updateUser(user); return Result.success(null); } @GetMapping("/{id}") public Result<User> getUserById(@PathVariable Long id) { return Result.success(userService.getUserById(id)); } @GetMapping("/page") public Result<PageResult<User>> getUserPage(@RequestParam(defaultValue = "1") int pageNum, @RequestParam(defaultValue = "10") int pageSize) { return Result.success(userService.getUserPage(pageNum, pageSize)); } }

先解释一下@RequestBody和@PathVariable的区别。@RequestBody接收的是请求体里的JSON数据，用于新增、修改这种需要传对象的场景；@PathVariable接收的是URL路径里的参数，用于删除、查询详情这种简单传ID的场景。很多新手混用，一个删除接口传一大包JSON过去，很不规范。

分页参数pageNum和pageSize我用@RequestParam接收，并给了默认值，这样前端不传参时也能正常返回第一页。在Service层做一个转换，把用户传的"页码"转换成SQL需要用的"偏移量"：

@Override public PageResult<User> getUserPage(int pageNum, int pageSize) { int offset = (pageNum - 1) * pageSize; List<User> userList = userMapper.selectPage(offset, pageSize); long total = userMapper.count(); PageResult<User> pageResult = new PageResult<>(); pageResult.setList(userList); pageResult.setTotal(total); pageResult.setPageNum(pageNum); pageResult.setPageSize(pageSize); return pageResult; }

这里的计算结果为什么要写出来，因为很多人在分页上栽跟头。pageNum=1时offset=0，查第一页就是从第0条开始取pageSize条；pageNum=2时offset=10，表示跳过第一页的10条，从第11条开始取。这是最基础的逻辑，但一旦前端传入的是"从0开始"的页码，offset的计算方式就要跟着变。我统一约定pageNum从1开始，不容易混乱。

3.6 全局异常处理：别让堆栈跑给前端看

写CRUD最烦的是什么？是明明业务校验已经抛了异常，Spring Boot默认返回的却是一大段英文堆栈信息。前端看到这种内容毫无体验感，而且还会把数据库结构等内部细节暴露出去。

所以我实现了一个全局异常处理器，用Spring的@RestControllerAdvice来实现：

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(RuntimeException.class) public Result<Void> handleRuntimeException(RuntimeException e) { return Result.error(e.getMessage()); } @ExceptionHandler(Exception.class) public Result<Void> handleException(Exception e) { return Result.error("系统异常，请联系管理员"); } }

@RestControllerAdvice是Spring MVC提供的全局异常处理机制，Controller里抛出的异常会自动被对应类型的@ExceptionHandler方法捕获。业务异常的message直接返回给前端，这样我在Service层抛的"用户名已存在"就能原样展示给用户。但内部未知异常不能暴露detail，统一返回"系统异常"，避免泄漏系统细节。这个机制让Controller真正"瘦"下来，不需要每个方法都try-catch，而且异常处理的逻辑集中在一处。

4. 常见问题与排查技巧实录

4.1 版本兼容问题：Spring Boot 3.x的javax与jakarta

我遇到的第一个大坑就是Spring Boot版本导致全盘编译失败。Spring Boot 3.0把Java EE API的包名从javax迁移到了jakarta，所有的注解像@TableName、@Resource、@PostConstruct，import路径全变了。如果你跟着网上的旧教程写代码，import javax.annotation.Resource直接报"程序包不存在"。

解决办法很简单，创建项目的时候别贪新，选择Spring Boot 2.7.x。等你熟悉了Spring Boot 3的包名变化再迁移也不迟。我自己的经验是，这个项目先用2.7.x把核心逻辑跑通，后面用3.x复刻一遍，顺便理解整个生态的演进，比一开始就硬啃新版文档效率高得多。

另外注意MyBatis的starter版本也要匹配，Spring Boot 2.7.x对应的mybatis-spring-boot-starter用2.3.x版本，避免在POM里乱挂高版本导致自动配置失效。

4.2 注入为null：忘记加注解还是没扫到包

第一次测试时，Service调用Mapper报了空指针异常，调试发现userMapper是null。我当时第一反应是接口忘记加@Mapper注解，加上以后又发现Application启动类没加@MapperScan。其实这个问题的本质是Spring容器里没有对应的Bean，原因无非三种：忘记加@Mapper/@Repository注解、Application启动类没有扫描到mapper包、或者多个mapper接口没有统一管理。

我后来的规范做法是，在Application启动类上加@MapperScan("com.example.userdemo.mapper")，这样整个mapper包下的接口都会被扫描注册为Bean。如果你在公司项目里看到这种写法，说明团队已经把这些基础配置沉淀成了规范，不用每个接口都手动加注解。

4.3 中文乱码：数据库连接串与页面编码

中文乱码这个问题在本地开发时最容易遇到。明明MySQL表设的是utf8mb4，插入一条中文用户名，查询出来全变成问号。我踩过之后总结了三个层面的检查顺序。

数据库层面，确认表和字段的字符集都是utf8mb4，用这条SQL检查：SHOW CREATE TABLE sys_user。连接层面，确认JDBC URL里有characterEncoding=utf8，这是最高频的原因。代码层面，确保IDE的全局编码是UTF-8，IDEA在Settings里设置File Encoding。

4.4 接口返回的字段少了或为null

这也是一类集中出现的问题。查询用户列表接口返回的数据里，createTime和updateTime永远是null，其他字段正常。这多半是MyBatis驼峰映射没开。

我在前面已经提到，application.yml里要加mybatis.configuration.map-underscore-to-camel-case=true。如果没加，MyBatis默认把create_time的字段名映射到Java实体的create_time属性上，而实体属性叫createTime，对不上自然就是null。还有一种情况是resultMap写死了映射字段，如果resultMap里没写createTime的映射，即使开启驼峰转换也不会生效。这两个因素叠加在一起，是排查点最多的区域。

4.5 前端到底用什么测试接口最方便

这个阶段不需要写前端页面。我强烈推荐用Postman来测试。新建一个请求，选择方法，填URL，切到Body页签选择raw和JSON格式，把参数写成JSON对象。新增用户就发这样的请求：

{ "username": "testuser", "password": "123456", "email": "test@example.com", "phone": "13800000000", "status": 1 }

如果手边没有Postman，用浏览器也能验证查询接口。直接访问http://localhost:8080/api/user/page?pageNum=1&pageSize=10，返回的JSON数据就是你这套三层架构联通的最直观证明。我从多年的实操体验看，先搞清楚接口的数据流转比急着做页面重要十倍，页面只是个展示载体，核心逻辑全在后端这几层里。

5. 测试顺序与常见问题的排查速查表

5.1 推荐的功能测试顺序

我建议你按"新增用户→查询用户详情→修改用户→分页查询→删除用户"的顺序来测，这个顺序刚好符合数据的生命周期，也便于你在每一步都能看到前一步操作的结果。

第一步，新增一个用户，然后立刻去数据库表里看数据有没有插入成功。确认密码被BCrypt加密了，create_time自动填了当前时间，id自动生成了。这些基础确认做完，基本说明数据源、Mapper、事务都是通的。

第二步，查询这个用户详情，确认createTime和updateTime能正常返回。如果返回为null，就去检查驼峰映射和resultMap，这是最常见的首坑。

第三步，修改用户信息，把邮箱和手机号改掉，再去查询确认修改生效。注意看updateTime是否更新成了最新时间，这能确认MySQL的ON UPDATE CURRENT_TIMESTAMP是否生效。

第四步，分页查询，先往表里插入两三条数据，再请求pageNum=1&pageSize=2，确认只返回两条，并且pageNum=2能返回剩余的数据。

最后再测删除，删除后立刻去查询详情，应该得到"查询不到"的结果。你可以看看我在Controller里没有对查询结果为null做特殊处理，如果你直接返回success(null)，前端就会拿到data为null的响应，这也是实际项目里的一个待优化点。

5.2 问题排查速查表

5.3 三层架构的常见误区：事务到底放在哪一层

写CRUD的时候还有一个高频问题：事务注解@Transactional该加在Controller还是Service？答案很明确，加在Service实现类的方法上。为什么？因为Service层是业务操作的最小单元。一个业务操作可能涉及多个Mapper方法调用，比如新增用户时要先查重、再插入、再记录日志，中间任何一步失败，整个操作都应该回滚。如果把事务放在Controller层，粒度太粗，不同接口间的非业务操作也被卷入同一个事务；如果放在Mapper层，单个SQL操作天然有事务但无法协调多个SQL操作的一致性。

这个设计背后是"事务的边界应该等于业务用例的边界"这样的思想。写CRUD时养成在Service实现类方法上标注@Transactional的习惯，等遇到复杂业务时就不会因为事务边界模糊而把数据改坏。

5.4 我踩过的低效调试方式

分享一个实操心得。这个项目在排查问题时，我见过太多新手直接在代码里System.out.println("查看数据为：" + user)，这种方式在小项目里勉强能用，但一旦数据量大或者并发高，很容易被大量日志冲刷掉关键信息。

我建议用日志框架统一输出，在application.yml里配置好spring级别、项目包级别的日志级别。MyBatis日志模块可以配置com.example.userdemo.mapper为DEBUG级别，这样控制台会直接打印出每条SQL和参数，排查SQL问题特别方便。这才是高效的调试姿势，省去看一眼少一眼的System.out。

6. 进阶扩展方向与个人经验总结

6.1 从三层到更细的分层：要不要加Manager

如果你照着上面的代码写完，你的项目就是一个标准的Controller-Service-Mapper三层架构。但真实企业项目里，很多会在Service下面再加一层Manager或者DAO扩展层，用来放分布式锁、缓存操作、多个Mapper的组合调用。

不过对新手来说，先别急着给架构加戏。三层的价值在于它把最核心的调用链理清了，在这个基础上有问题再看有没有扩展必要。我见过不少初级开发把Manager层再加一个，结果整个项目变得极其臃肿，反而把简单CRUD架复杂了。先把三层架构写熟，理解了每一层的边界，再学更复杂的架构设计是正道。

6.2 逻辑删除 vs 物理删除：生产环境的现实选择

我在前面埋了一个伏笔，关于删除用户。上面的代码用的是物理删除，直接DELETE，数据彻底消失。在一些小项目里，这样可以接受。但真实系统的用户数据通常是不能物理删除的，因为用户的历史订单、操作记录还需要关联查询。所以生产环境中更常见的是逻辑删除，也就是在表里加一个deleted字段，删除操作只是一个UPDATE把deleted置为1，查询时默认过滤掉这些已删除的数据。

这个改进也不复杂，把deleteById改成updateUserStatus，把查询SQL加上deleted = 0条件就行。但从物理删除到逻辑删除的转变，是把"能跑"变成"能用于实际"的关键一步，建议你理解物理删除的写法后，自己动手改造一遍。

6.3 如何把CRUD项目扩展成真正的系统

如果你拿这份代码做毕设或者课设，一定会在答辩时被问"你这个系统除了CRUD还有什么亮点"。最实用的几个扩展方向我按难度排个顺序：

最简单的扩展：加一个参数校验框架，用@Valid配合@NotNull这些注解替换手写校验；加一个Swagger接口文档，把接口定义自动生成可视化文档；加一个统一日志切面，用AOP记录每个接口的调用耗时。

中等难度的扩展：引入MyBatis-Plus替代原生MyBatis，内置分页插件和通用Mapper，简化大量重复代码；集成Redis缓存用户列表；做一个简单的登录功能，用JWT实现认证。

较高难度的扩展：做用户权限控制，引入Spring Security；做接口限流、敏感字段脱敏；把模块拆分成独立的微服务。

6.4 最后分享几个坚持至今的编码习惯

我个人在实际做项目的过程中，养成了几个对新手很实用的习惯，在这里分享出来。

我总是把接口返回结构统一，无论成功失败都用Result包装，这样前端写起来只有一个逻辑分支。命名上坚持语义化，Controller方法名叫addUser而不是add，Mapper方法名直接跟SQL动词对应，代码读起来跟读需求文档一样顺。每个业务方法我都习惯先在Service里想清楚数据从哪里来、中间要做什么处理、最终返回什么，再动手写代码。

写代码慢不可怕，最怕的是不清不楚就开始写，写到一半发现设计不对，回炉重造的成本最高。这也是为什么我在文章里花了这么多篇幅讲设计思路和为什么这么选，就算你照着抄代码，也要知道每一行背后的道理。这个读者如果能顺着这个思路把Spring Boot的CRUD吃透，后续不管学Redis、RabbitMQ还是Spring Cloud，都会比别人多一个"架构视角"，而不只是会调接口的工具人。