一、知识回顾（读完直接做下面的实践题）#

1. 需求：往 dept 表插一条数据；页面上是”+ 新增部门”→ 弹窗只填部门名称（必填、长度 2-10 位）→ 确定；接口文档：POST /depts、格式 application/json、参数 name（string，必须）、样例 {"name": "教研部"}
2. 三层的职责（PPT 第 50 页）：Controller 接收请求参数（JSON）→ 调用 Service → 响应结果；Service 补全基础属性（create_time、update_time）→ 调 Mapper；Mapper 执行 insert into dept(name, create_time, update_time) values (?, ?, ?)
3. JSON 参数的接收规则（PPT 第 51 页）：通常用一个实体对象接收；JSON 的键名要与对象属性名相同；必须加 @RequestBody 注解
4. 为什么用实体对象：请求体里是一整个 JSON 对象，实体对象能把键按名逐个填进属性；字段多了不用改方法签名，没传的字段保持 null（本机日志里 Dept(id=null, name=测试部, createTime=null, updateTime=null)）
5. 键名对不上的后果：不报错，但那个属性收不到值（是 null）——数据悄悄丢了
6. 为什么时间要后端补：弹窗里用户只填名字；dept 表两个时间列是 DEFAULT NULL、没有自动填时间的默认值；“新增时记录创建时间/修改时间”是业务规则，归 Service
7. 补全的写法：dept.setCreateTime(LocalDateTime.now());、dept.setUpdateTime(LocalDateTime.now());——LocalDateTime.now() 取服务器当前时间
8. Mapper 写法：@Insert("insert into dept(name, create_time, update_time) values(#{name}, #{createTime}, #{updateTime})")——注意 #{} 里是实体属性名（驼峰），id 是自增主键不用写
9. 本机实测：POST /depts（请求体 {"name":"测试部"}）→ {"code":1,"msg":"success","data":null}；MyBatis 日志 ==> Preparing: insert into dept(name, create_time, update_time) values(?,?,?)；插完的记录里两个时间都被 Service 填上了同一个时刻
10. JSON 参数的适用场景（PPT 第 53 页）：主要在 POST、PUT 请求里，用请求体传参数（GET/DELETE 的简单参数走地址栏，对照60 篇）

二、裸写题#

• 2-1 开发”新增部门”的接口 需求：页面弹窗里填好部门名称点”确定”后，往数据库 dept 表插一条记录。接口地址 /depts、请求方式 POST、参数用 JSON 放在请求体里（形如 {"name":"教研部"}，前端只传这一个字段）；三层都要写：Controller 接参数、调 Service、返回统一响应结果；两个时间字段由 Service 补全为当前时间再交给 Mapper；SQL 只写要插的三列（主键自增不用写）。tlias 库的 dept 表结构见练习文件，Dept 实体类（id / name / createTime / updateTime）已备好。 （练习文件 test_61_新增部门接口.java 的题目2-1 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先定”请求方式和参数来源”（POST + 请求体 JSON → 用实体对象接，加”从请求体取参数”的注解）；再把”补时间”写在 Service；最后 Mapper 上写 insert，占位符按实体属性名写 二级 · 方法：@PostMapping + @RequestBody Dept dept；Service 里 dept.setCreateTime(LocalDateTime.now())、dept.setUpdateTime(LocalDateTime.now()) 后调 deptMapper.insert(dept)；Mapper 用 @Insert("insert into dept(name, create_time, update_time) values(#{name},#{createTime},#{updateTime})")；返回 Result.success() 三级 · 骨架：

  • Controller：@PostMapping public Result ____(@____ Dept dept){ deptService.____(dept); return Result.____(); }
  • Service：dept.set____(LocalDateTime.____()); dept.set____(LocalDateTime.now()); deptMapper.____(dept);
  • Mapper：@Insert("insert into dept(____, ____, ____) values(#{name}, #{createTime}, #{updateTime})") void insert(____ dept);
  参考答案（做完再点开）

  与课程 代码/tlias-web-management 一致（PPT 里 Mapper 方法名叫 add，工程里叫 insert；代码里的 log 来自 63 篇要讲的 @Slf4j，还没学到就先写 System.out.println）：

  1
  // ===== Controller 层：接收请求参数（JSON）+ 调用 Service + 响应结果 =====
  2
  @RestController
  3
  @RequestMapping("/depts")
  4
  public class DeptController {
  5
  
  6
      @Autowired
  7
      private DeptService deptService;
  8
  
  9
      /**
  10
       * 新增部门
  11
       */
  12
      @PostMapping
  13
      public Result add(@RequestBody Dept dept){
  14
          log.info("新增部门:{}", dept);
  15
          deptService.add(dept);
  16
          return Result.success();
  17
      }
  18
  }

  显示更多显示更少

  1
  // ===== Service 层：补全基础属性 + 调 Mapper =====
  2
  public interface DeptService {
  3
      void add(Dept dept);
  4
  }
  5
  
  6
  @Service
  7
  public class DeptServiceImpl implements DeptService {
  8
  
  9
      @Autowired
  10
      private DeptMapper deptMapper;
  11
  
  12
      @Override
  13
      public void add(Dept dept) {
  14
          //1. 补全基础属性 - createTime, updateTime
  15
          dept.setCreateTime(LocalDateTime.now());
  16
          dept.setUpdateTime(LocalDateTime.now());
  17
  
  18
          //2. 调用Mapper接口方法插入数据
  19
          deptMapper.insert(dept);
  20
      }
  21
  }

  显示更多显示更少

  1
  // ===== Mapper 层：数据访问 =====
  2
  @Mapper
  3
  public interface DeptMapper {
  4
      /**
  5
       * 新增部门
  6
       */
  7
      @Insert("insert into dept(name, create_time, update_time) values(#{name}, #{createTime}, #{updateTime})")
  8
      void insert(Dept dept);
  9
  }

  自查：① 参数上的注解必须是 @RequestBody（不是 @RequestParam）——JSON 在请求体里；② 三个 #{} 写的是实体属性名（createTime 而不是 create_time）；③ 只插三列、id 留给数据库自增；④ 时间在 Service 里补，不在 Controller 也不在 Mapper。 本机实测这条链路：{"code":1,"msg":"success","data":null}，日志里 SQL 是 insert into dept(name, create_time, update_time) values(?,?,?)。

• 2-2 写对”接收 JSON 参数”的方法签名 需求：前端会发来 POST /depts，请求体是 {"name":"教研部"}（Content-Type: application/json）。请：① 写出 Controller 里接收它的方法签名（含路径、请求方式、参数、返回值）；② 写出被接收的实体类（用 Lombok 省掉 getter/setter）；③ 说明”键名与属性名一致”这条规则——如果前端传的是 {"deptName":"教研部"}，这次插入会发生什么？ （练习文件 test_61_新增部门接口.java 的题目2-2 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：先判断”参数在哪”（请求体，不是地址栏）→ 决定用哪种接收方式（实体对象 + 那个注解）→ 实体类的属性名要和 JSON 键名一一对应 二级 · 方法：@PostMapping + @RequestBody Dept dept；实体类用 @Data（Lombok）生成 getter/setter，属性 Integer id / String name / LocalDateTime createTime / LocalDateTime updateTime 三级 · 骨架：① @PostMapping("____") public Result add(@____ ____ dept){ … }；② @Data public class ____ { private Integer ____; private String ____; private LocalDateTime ____; private LocalDateTime ____; }；③ 键名 deptName 与属性名 ____ 不一致 → 属性收到 ____，插入的名字是 ____

  参考答案（做完再点开）

  ① 方法签名：

  1
  @PostMapping("/depts")
  2
  public Result add(@RequestBody Dept dept){
  3
      deptService.add(dept);
  4
      return Result.success();
  5
  }

  ② 实体类（课程工程 pojo/Dept.java）：

  1
  @Data
  2
  @NoArgsConstructor
  3
  @AllArgsConstructor
  4
  public class Dept {
  5
      private Integer id;                // ID
  6
      private String name;               // 部门名称
  7
      private LocalDateTime createTime;  // 创建时间
  8
      private LocalDateTime updateTime;  // 修改时间
  9
  }

  ③ 键名 deptName 与属性名 name 对不上：SpringMVC 找不到叫 deptName 的属性，dept.name 收不到值、保持 null——插入时 name 列会是空值（dept 表的 name 是 NOT NULL UNIQUE，这条 insert 会被数据库拒绝报错），而请求本身不会因为”多传了一个未知键”就报错。规则就是 PPT 那句：JSON 数据的键名与方法形参对象的属性名相同。 所以前端和实体类的字段名要按接口文档对齐（后端也可以通过 @JsonProperty 之类的注解做名字映射，课程里没用，保持同名最简单）。

• 2-3 两个时间字段该在哪一层补 需求：插入语句是 insert into dept(name, create_time, update_time) values(?,?,?)，但前端只传了 name。请回答：① 这两个时间应该在哪一层补、用什么代码？② 如果谁都不补，会发生什么（结合表定义 create_time datetime DEFAULT NULL、update_time datetime DEFAULT NULL 说明）；③ 为什么不让前端把时间传过来？ （练习文件 test_61_新增部门接口.java 的题目2-3 里给了写作区。）

  提示（先自己想，实在想不出再点开）

  一级 · 思路：问自己”这两个值的来源是用户的输入，还是服务器的规则”——不是用户输入的，就该在后端按规则生成；层与层的分工里，规则归 Service 二级 · 方法：Service 里用 setCreateTime(...) / setUpdateTime(...)，值取 LocalDateTime.now()；不补则两个占位符拿到 null，而表定义允许 NULL（DEFAULT NULL）→ 存进去就是 NULL 三级 · 骨架（答题骨架）：① 在 ____ 层补：dept.set____(LocalDateTime.____());；② 不补 → 两列存成 ____（表定义是 ____，不会报错）；③ 不让前端传是因为时间是 ____（服务器时间/统一规则），前端时钟不可信、还可能被改

  参考答案（做完再点开）

  ① 在 Service 层补（DeptServiceImpl.add 里）：

  1
  dept.setCreateTime(LocalDateTime.now());   // 创建时间 = 当前时间
  2
  dept.setUpdateTime(LocalDateTime.now());   // 修改时间 = 当前时间

  ② 谁都不补的话，insert 的三个占位符里后两个是 null；而 dept 表的两列定义是 datetime DEFAULT NULL（允许为空，也没有自动填时间的默认值），所以数据库不会拒绝——那条记录的”最后修改时间”就永远是空的（页面上那一列空白）。这类”能写进去但没意义”的数据，正是要靠 Service 层的业务规则保证的； ③ 因为”什么时候创建的、最后什么时候改的”是服务器侧的规则，不该由客户端说了算：前端时钟可能不准（用户电脑时间随便改），多台机器还可能时区不同；统一由后端 LocalDateTime.now() 生成（本机实测：前端只传了 {"name":"测试部"}，插入后 createTime 与 updateTime 都是同一个时刻 2026-09-29T19:11:59），数据才一致可信。顺带一提，修改部门时只需补 updateTime（创建时间不动）——62 篇再说。

三、综合题#

• 3-1 把新增部门从接口做到页面上点得动 照着课程把这一站走一遍：写代码 → 启动 → 发 JSON → 看日志 → 查数据 → 页面上点。

  1. 在 DeptMapper、DeptService/DeptServiceImpl、DeptController 三层把”新增部门”写齐（方法名课堂工程用 insert / add，PPT 里 Mapper 叫 add）；
  2. 启动工程，用 Apifox（或 curl --data-binary @body.json）发一次 POST /depts，请求体写 {"name":"测试部"}，把返回的 JSON 抄下来；先别急着往下做：回到控制台，把这次请求打出来的日志抄下来（至少两条：Controller 里打印的那个 Dept(...) 对象、MyBatis 的 Preparing: insert ... 那一行）；
  3. 观察第 2 步里那个 Dept(...) 对象的四个字段：哪几个有值、哪几个是 null？再对照 MyBatis 的 Preparing 语句里有几个 ?——说出这两个时间是在哪一层、什么时候被填进去的；
  4. 去客户端执行 select * from dept order by update_time desc;，确认新记录进去了、id 是自增的、两个时间都有值，把这一行抄下来；
  5. 把59 篇的前端工程起着（90），到页面上点”+ 新增部门”→ 填一个部门名字 → 确定，看表格第一行是不是刚新增的那条（58 篇的排序是 update_time desc，新加的排最前）；
  6. 收尾：把自己造的测试数据删掉（可以就用60 篇写的删除接口），把表恢复成原来的样子；再回答下面的两个问题。

  回答：① 这次插入只写了三个列，为什么不用写 id、也不用写别的时间格式化代码？② 如果让你把”新增部门”改成”新增班级”（表里字段有十来个），用 JSON + 实体对象接收比用地址参数有什么好处？ （练习文件 test_61_新增部门接口.java 的”综合题”一段里按这 6 步给了写作区。）

  涉及知识点

  知识点	在这里的应用
  需求与接口文档（PPT 49）	第 2、5 步——POST /depts、application/json、{"name":"教研部"}
  三层职责（PPT 50）	第 1、3 步——Controller 接参、Service 补时间、Mapper 插数据
  JSON 参数接收（PPT 51）	第 1、2 步——实体对象 + 键名一致 + @RequestBody
  自增主键	第 4 步——不写 id，数据库自动分配（本机实测新增的是 id=7）
  联调与列表排序（59、58 篇）	第 5 步——页面上点新增，新记录出现在表格第一行
  MyBatis 日志（本机实测）	第 2、3 步——Dept(...) 对象与 Preparing 三个 ? 的对照

  提示（先自己想，实在想不出再点开）

  一级 · 思路：这一题的关键不是”把代码写出来”，而是用日志证明”谁填了什么”——Controller 日志证明前端只传了 name，Preparing 语句证明 SQL 里确实有三个值在等着填 二级 · 方法：@PostMapping + @RequestBody Dept dept；Service 两行 setXxxTime(LocalDateTime.now())；Mapper 的 @Insert 里列名与 #{} 一一对应；验证用 Apifox / curl 发 JSON、DataGrip 或命令行查表、页面点按钮 三级 · 骨架：② 请求 POST http://localhost:8080/depts，body {"name":"____"}；③ 日志里 Dept(id=____, name=____, createTime=____, updateTime=____) 与 Preparing: insert into dept(____, ____, ____) values(?,?,?)；④ 查表 select * from dept order by ____ desc;

  参考答案（做完再点开）

  3-1

  1. 三层代码见 2-1 的参考答案（Controller add(@RequestBody Dept dept)、ServiceImpl 补两个时间、Mapper @Insert insert 三列）。
  2. 本机实测的响应与日志：

     1
     {"code":1,"msg":"success","data":null}

     1
     2026-09-29 19:11:58.632 [http-nio-8080-exec-8] INFO  com.itheima.controller.DeptController - 新增部门:Dept(id=null, name=测试部, createTime=null, updateTime=null)
     2
     ==>  Preparing: insert into dept(name, create_time, update_time) values(?,?,?)

  3. Dept(...) 里只有 name=测试部 有值，id、createTime、updateTime 都是 null——说明前端只传了名字；Preparing 语句里是三个 ?（name、create_time、update_time）。两个时间的值来自 Service 层的 dept.setCreateTime(LocalDateTime.now()) / dept.setUpdateTime(LocalDateTime.now())，是在”进 Mapper 之前”补上的（所以 Controller 里打印时它们还是 null）。
  4. 查表（本机实测的新增结果）：id=7、name=测试部、create_time 与 update_time 都是 2026-09-29T19:11:59——id 是自增的，时间由 Service 补全。（在客户端里这行显示为 2026-09-29 19:11:59，JSON 里带 T 是序列化格式的差别。）
  5. 页面上点”+ 新增部门”，填名字点确定，表格刷新后新记录排在第一行（因为查询 SQL 是 order by update_time desc，刚插进去的 update_time 最新）；经反向代理时前端发的是 POST /api/depts，被 nginx 摘掉前缀转成 POST /depts（59 篇）。
  6. 两个回答： ① id 是自增主键（id int unsigned PRIMARY KEY AUTO_INCREMENT），值由数据库分配，写进去反而多余（44 篇）；也不用写时间格式化代码，是因为两个时间由 Service 用 LocalDateTime.now() 生成，MyBatis 会把它按 datetime 列的格式交给数据库——插入语句里只需要三个占位符； ② JSON + 实体对象的两个好处：一是字段多也不怕（十来个字段还是同一个方法签名，JSON 的键按名字自动填进属性，不用写十来个方法参数）；二是结构清晰、适合传对象（JSON 能带嵌套、数组，Content-Type: application/json 也自解释了数据格式），而地址栏参数适合 id 这类零散的简单值，字段一多又会撞上 URL 长度与编码的麻烦。这也是 PPT 第 53 页那句”JSON 参数主要在 POST、PUT 请求的请求体里传”的原因。