方式一：用 HttpServletRequest 自己取（PPT 第 41 页）#

1
@DeleteMapping("/depts")
2
public Result delete(HttpServletRequest request){
3
    String idStr = request.getParameter("id");   // 取出的是 String
4
    int id = Integer.parseInt(idStr);            // 还得自己转型
5
    System.out.println("根据ID删除部门: " + id);
6
    return Result.success();
7
}

请求对象 HttpServletRequest 是 33 篇学过的老熟人——Tomcat 解析请求后封装的对象，getParameter("id") 按名字取请求参数。PPT 在代码旁边标了两个词：繁琐、手动类型转换。具体繁在哪：

• getParameter 返回的永远是 String，数字要自己 Integer.parseInt(idStr) 转，转错了运行期才炸；
• 每多一个参数就多两行样板代码（取名 + 转型）；
• 参数没传时 idStr 是 null，Integer.parseInt(null) 会直接抛异常，还得自己判空。

方式二：用 @RequestParam 把请求参数绑定给形参（PPT 第 42 页）#

1
@DeleteMapping("/depts")
2
public Result delete(@RequestParam("id") Integer deptId){
3
    System.out.println("根据ID删除部门: " + deptId);
4
    return Result.success();
5
}

@RequestParam("id") 的意思是：去请求参数里找名叫 id 的那个值，绑定到这个形参上。注意形参可以叫别的名字（这里叫 deptId），注解里的 "id" 才是请求参数名。相比方式一，好处是：SpringMVC 顺手做了类型转换（"8" → Integer 8），不用再写 parseInt。

PPT 在这页底下放了一条注意：

@RequestParam 注解 required 属性默认为 true，代表该参数必须传递，如果不传递将报错。如果参数可选，可以将属性设置为 false。

课程代码里那段被注释掉的写法正好演示了”可选”的版本：

1
@RequestParam(value = "id", required = false) Integer deptId

方式三：参数名与形参名一致，直接写形参（PPT 第 43 页，推荐）#

1
@DeleteMapping("/depts")
2
public Result delete(Integer id){
3
    System.out.println("根据ID删除部门: " + id);
4
    return Result.success();
5
}

PPT 第 43 页的说法是：如果请求参数名与形参变量名相同，直接定义方法形参即可接收（省略 @RequestParam）。请求参数叫 id、形参也叫 id，SpringMVC 就自动对上了，连注解都省了。课程代码在注释里把这一种标为 [推荐]：

1
/**
2
 * 删除部门 - 方式三: 省略@RequestParam (前端传递的请求参数名与服务端方法形参名一致) [推荐]
3
 */
4
@DeleteMapping
5
public Result delete(Integer id){
6
    log.info("根据ID删除部门: {}", id);
7
    deptService.deleteById(id);
8
    return Result.success();
9
}

（这里方法上写的是 @DeleteMapping、不带路径，因为类上已经有 @RequestMapping("/depts")——完整路径是”类上的 + 方法上的”拼起来，62 篇会专门讲这条规则。）

三种方式对照（PPT 第 44 页）#

PPT 第 44 页把三种写法归在一张表里，并重申了那条注意事项：

本机实测：不传 id 的两种结果（required 那条注意的实证）#

“必须传递”到底是什么意思？本机专门做了对照实验，把形参改来改去各发一次请求：

两条结论：

1. 加了 @RequestParam 就等于声明”这个参数必填”（required 默认 true），缺了直接被 SpringMVC 拦在方法外面（400），根本进不了你的方法体；
2. 不加注解时，包装类型（Integer）可以缺省，取到 null 也不会报错——代价是错误被悄悄吞掉：用户以为删了，服务器其实什么都没删（Updates: 0）。

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

1. 需求：页面操作列点”删除”→ 按这一行的主键 ID 删数据；接口文档：请求路径 /depts、请求方式 DELETE、参数 id（number，必须）、样例 /depts?id=1
2. 三层的职责（PPT 第 40 页）：Controller 接收请求参数（/depts?id=8）+ 调用 Service + 响应结果；Service 调 Mapper 接口方法；Mapper 执行 SQL delete from dept where id = ?
3. 方式一：用 HttpServletRequest 的 getParameter("id") 取——繁琐，返回 String 要手动类型转换，参数没传时 parseInt(null) 还会抛异常
4. 方式二：@RequestParam("id") Integer deptId 把请求参数绑定给形参——形参名可以与请求参数名不同，SpringMVC 自动做类型转换
5. 方式三（推荐）：请求参数名与形参变量名相同时，直接定义方法形参即可，省略 @RequestParam
6. 注意事项：一旦加了 @RequestParam，该参数必须传递——required 默认为 true，不传将被拦在方法外报错；要可选就设 required = false
7. 本机实测（不传 id）：形参是 Integer id 且没加注解 → 200 + success，Parameters: null、Updates: 0（删 0 行不报错）；形参加了 @RequestParam → 400 Bad Request，响应体是 Spring 默认错误 JSON，不是统一 Result
8. Mapper 写法：@Delete("delete from dept where id = #{id}")，方法名课程工程里叫 deleteById；#{} 是预编译占位符，最终 SQL 是 delete from dept where id = ?
9. 本机实测（删成功）：DELETE /depts?id=7 → {"code":1,"msg":"success","data":null}；MyBatis 日志 ==> Preparing: delete from dept where id = ?
10. 命令行坑：Windows 命令行参数是 GBK，curl -d '{"name":"测试部"}' 这类中文 JSON 会 400；把 JSON 存成 UTF-8 文件用 --data-binary @body.json 发，或直接用 Apifox

二、裸写题#

• 2-1 开发”根据 ID 删除部门”的接口 需求：页面操作列点”删除”时，把该行部门从数据库里删掉。接口地址 /depts、请求方式 DELETE、要删的部门 ID 跟着地址传（形如 /depts?id=8）；三层都要写：Controller 只负责接参数、调 Service、返回统一响应结果；Service 调 Mapper；Mapper 用一条删除的 SQL（条件按主键）。项目里已经准备好 Result 统一响应结果类、Dept/DeptService/DeptMapper 这些结构（57 篇搭的），表是 tlias 库的 dept。 （练习文件 test_60_删除部门接口.java 的题目2-1 里给了写作区。）

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

  一级 · 思路：先给 Controller 标”哪条路径、哪种请求方式”，形参就按”请求参数名与形参名一致”的推荐写法写；Service 只做转发；Mapper 上写删除 SQL，SQL 里用预编译占位符取形参 二级 · 方法：类上（或方法上）用 @DeleteMapping，方法形参写 Integer id；Service 里 deptMapper.deleteById(id)；Mapper 里 @Delete("delete from dept where id = #{id}")；返回 Result.success() 三级 · 骨架：

  • Controller：@DeleteMapping("____") public Result delete(Integer ____){ deptService.____(id); return Result.____(); }
  • Service：接口 void deleteById(____ id);，实现 deptMapper.____(id);
  • Mapper：@Delete("delete from dept where ____ = #{id}") void deleteById(____ id);
  参考答案（做完再点开）

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

  1
  // ===== Controller 层：接收请求参数 + 调用 Service + 响应结果 =====
  2
  @RestController
  3
  @RequestMapping("/depts")
  4
  public class DeptController {
  5
  
  6
      @Autowired
  7
      private DeptService deptService;
  8
  
  9
      /**
  10
       * 根据 ID 删除部门
  11
       */
  12
      @DeleteMapping
  13
      public Result delete(Integer id){
  14
          log.info("根据ID删除部门: {}", id);
  15
          deptService.deleteById(id);
  16
          return Result.success();
  17
      }
  18
  }

  显示更多显示更少

  1
  // ===== Service 层：业务处理（这里只做转发） =====
  2
  public interface DeptService {
  3
      void deleteById(Integer id);
  4
  }
  5
  
  6
  @Service
  7
  public class DeptServiceImpl implements DeptService {
  8
  
  9
      @Autowired
  10
      private DeptMapper deptMapper;
  11
  
  12
      @Override
  13
      public void deleteById(Integer id) {
  14
          deptMapper.deleteById(id);
  15
      }
  16
  }

  显示更多显示更少

  1
  // ===== Mapper 层：数据访问 =====
  2
  @Mapper
  3
  public interface DeptMapper {
  4
      /**
  5
       * 根据 ID 删除部门
  6
       */
  7
      @Delete("delete from dept where id = #{id}")
  8
      void deleteById(Integer id);
  9
  }

  自查：① 类上写了 @RequestMapping("/depts") 时，方法上 @DeleteMapping 可以不带路径（完整路径 = 类上 + 方法上的）；② #{} 里的名字要和 Mapper 方法的形参名对得上（#{id} ↔ Integer id）；③ 删除没有要加工的字段，所以 Service 里不写业务处理，但也不能省掉这一层去 Controller 里直接调 Mapper。 本机实测这条链路的结果：DELETE /depts?id=7 → {"code":1,"msg":"success","data":null}。

• 2-2 同一个参数，三种写法各写一遍 需求：上面那个删除接口，请把接收 id 的三种写法各写一遍：① 用请求对象自己取（并说明为什么它”繁琐”）；② 用注解把请求参数绑定给形参（形参故意取一个与请求参数不同的名字）；③ 靠”请求参数名与形参名一致”省略注解。写完说明实际项目里选哪种、为什么。 （练习文件 test_60_删除部门接口.java 的题目2-2 里给了写作区。）

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

  一级 · 思路：三种写法的差别只在方法签名上（怎么把请求里的 id 拿到手），其余三层的代码完全一样 二级 · 方法：① HttpServletRequest + getParameter + 手动 Integer.parseInt；② @RequestParam("id") Integer deptId；③ @DeleteMapping + Integer id 三级 · 骨架： ① public Result delete(____ request){ String idStr = request.____("id"); int id = Integer.____(idStr); … } ② public Result delete(@____("id") Integer ____){ … } ③ public Result delete(Integer ____){ … }

  参考答案（做完再点开）

  1
  // 方式一：原始的 HttpServletRequest（繁琐 + 手动类型转换）
  2
  @DeleteMapping("/depts")
  3
  public Result delete(HttpServletRequest request){
  4
      String idStr = request.getParameter("id");   // 取出来是 String
  5
      int id = Integer.parseInt(idStr);            // 自己转型，参数没传时还会抛异常
  6
      System.out.println("根据ID删除部门: " + id);
  7
      return Result.success();
  8
  }
  9
  
  10
  // 方式二：@RequestParam 绑定（形参名可以和请求参数名不一样）
  11
  @DeleteMapping("/depts")
  12
  public Result delete(@RequestParam("id") Integer deptId){
  13
      System.out.println("根据ID删除部门: " + deptId);
  14
      return Result.success();
  15
  }
  16
  
  17
  // 方式三：请求参数名与形参名一致，省略注解（推荐）
  18
  @DeleteMapping("/depts")
  19
  public Result delete(Integer id){
  20
      System.out.println("根据ID删除部门: " + id);
  21
      return Result.success();
  22
  }

  显示更多显示更少

  项目里选方式三：最常见、最短（PPT 第 43/44 页都标为推荐）；只有”请求参数名与形参名不一致”或”要控制必填/可选”时才用方式二（@RequestParam(value = "id", required = false)）；方式一是 Servlet 时代的做法，查参数多、还要手动转型，现在只用来理解”请求参数从哪来”。

• 2-3 参数不传会怎样：把两种结果解释清楚 需求：有人用工具发了一次 DELETE /depts——不带 id。请回答：① 如果方法形参是 Integer id 且没有加 @RequestParam，这次请求的状态码是什么、数据库里会发生什么？（结合服务端日志里的 Parameters 与 Updates 说明）② 如果形参加的是 @RequestParam Integer id，结果又是什么？③ 想让这个参数”可选”，注解上要加什么属性、写成什么样？ （练习文件 test_60_删除部门接口.java 的题目2-3 里给了写作区。）

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

  一级 · 思路：两问的区别是”有没有加注解”——不加注解没人检查参数在不在，加了注解就默认必填；@RequestParam 控制必填/可选的属性叫 required 二级 · 方法：不加注解 → 形参取到 null → SQL 的 where id = null 匹配不到任何行（Updates: 0）；加注解 → 参数缺失，SpringMVC 在调用方法前就返回 400；可选写成 @RequestParam(value = "id", required = false) 三级 · 骨架（答题骨架）：① 状态码 ____，日志 Parameters: ____、Updates: ____，结果是 ____；② 状态码 ____，响应体是 ____；③ 写法 @RequestParam(value = "id", required = ____) Integer id

  参考答案（做完再点开）

  ① 200 + success。id 取到 null，MyBatis 日志里是 ==> Parameters: null、<== Updates: 0——一条也没删，但接口”成功”了（本机实测）。这是最坑的一种：前端以为删掉了，数据库纹丝不动； ② 400 Bad Request，而且进不了你的方法体——SpringMVC 在参数绑定阶段就拒绝了；响应体是 Spring 默认的错误页 {"timestamp":…,"status":400,"error":"Bad Request"}，不是统一响应结果 Result（本机实测）。原因是 @RequestParam 的 required 默认是 true（PPT 第 42/44 页的注意）； ③ 把必填改成可选：@RequestParam(value = "id", required = false) Integer deptId（课程代码里注释掉的那段就是这么写的）。改成可选之后不传 id，行为回到 ① —— 能进方法，但 id 是 null，同样删不到东西，所以真正的做法是在 Service 里对 null 做判断并返回失败结果。

三、综合题#

• 3-1 把删除部门从接口做到页面上点得动 照着课程把这一站的完整流程走一遍：写代码 → 启动 → 测接口 → 看日志 → 页面上点。

  1. 在工程的 DeptMapper、DeptService/DeptServiceImpl、DeptController 三层里把”根据 ID 删除部门”的方法补齐（课堂代码里的方法名是 deleteById）；
  2. 启动工程，用 Apifox（或命令行 curl -X DELETE，注意别在命令行里发中文）发一次 DELETE /depts?id=1，把返回的 JSON 抄下来；
  3. 去客户端里执行 select * from dept; 确认那条记录真的没了（测完记得把数据恢复回去：重新执行一遍 dept.sql 里的 insert）；
  4. 故意做一次对照实验：把 id 去掉再发一次同样的请求，先把当时的控制台日志（Parameters、Updates 两行）抄下来；再把形参改成”必须传递”的绑定写法（@RequestParam）重启，重复一次不带 id 的请求，记录状态码和响应体；
  5. 把59 篇的前端工程起着（90），在后端的删除接口做好之后，到页面上点某一行的”删除”，观察表格是不是少了一行；
  6. 收尾回答下面的两个问题。

  回答：① 这一站里”接收参数”为什么放在 Controller、而”删除条件”为什么要写成主键？② 两次对照实验（不加注解 / 加注解）的结果，说明了 @RequestParam 的什么特性？ （练习文件 test_60_删除部门接口.java 的”综合题”一段里按这 6 步给了写作区。）

  涉及知识点

  知识点	在这里的应用
  需求与接口文档（PPT 39）	第 1、2 步——DELETE /depts、参数 id 必填、样例 /depts?id=1
  三层职责（PPT 40）	第 1 步——Controller 接参、Service 转发、Mapper 写 SQL
  简单参数三种接收方式（PPT 41～44）	第 2、4 步——推荐写法 + 对照实验
  required 默认 true（PPT 42、44）	第 4 步——不传 id 的两种结果（200 vs 400）
  联调（59 篇）	第 5 步——页面上点”删除”验证整条链路
  MyBatis 日志（本机实测）	第 4 步——Parameters、Updates 两行是判断”删没删到”的依据

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

  一级 · 思路：写代码只写三层里”删除”这一条线；实验的变量只有一个——形参上有没有 @RequestParam，其余条件（同一地址、同样不带 id）保持一致 二级 · 方法：Mapper 用 @Delete + #{id}；Controller 推荐写法是 public Result delete(Integer id)；对照实验把形参改成 @RequestParam Integer id 重启后再发一次 三级 · 骨架：① @DeleteMapping + public Result delete(____ id) → deptService.____(id)；② 请求 DELETE http://localhost:8080/depts?id=____；③ 日志 ==> Preparing: delete from dept where id = ____、<== Updates: ____；④ 加注解后不传 id → 状态码 ____

  参考答案（做完再点开）

  3-1

  1. 三层代码（与 2-1 答案一致，方法名用工程的 deleteById；log 来自 @Slf4j，见 2-1 答案里的说明）：

     1
     @DeleteMapping
     2
     public Result delete(Integer id){        // Controller：接收请求参数
     3
         log.info("根据ID删除部门: {}", id);
     4
         deptService.deleteById(id);
     5
         return Result.success();
     6
     }
     7
     
     8
     @Override
     9
     public void deleteById(Integer id) {     // Service：调用 Mapper
     10
         deptMapper.deleteById(id);
     11
     }
     12
     
     13
     @Delete("delete from dept where id = #{id}")
     14
     void deleteById(Integer id);             // Mapper：SQL delete from dept where id = ?

  2. 本机实测返回：{"code":1,"msg":"success","data":null}（data 是空——删除不需要回数据）。
  3. select * from dept; 里那条已经查不到了；恢复数据用 dept.sql 里的 insert 语句重新插回去。
  4. 两次对照实验（本机实测）：
     • 形参 Integer id、不加注解，发 DELETE /depts（不带 id）→ 200 + success，日志 ==> Parameters: null / <== Updates: 0（删 0 行，不报错）；
     • 形参改成 @RequestParam Integer id，同样不带 id → 400 Bad Request，响应体 {"timestamp":…,"status":400,"error":"Bad Request"}（Spring 默认错误页，不是统一 Result）。
  5. 联调：前端工程（90）在跑、后端接口写好之后，页面上点某行”删除”→ 表格少一行；经反向代理删的还是 /api/depts?id=xx 被摘成 /depts?id=xx（59 篇）。
  6. 两个回答： ① 请求参数是”从 HTTP 请求里取数据”，属于接收请求的职责，所以放 Controller（前端传什么、怎么对上是接口层的事）；删除必须按主键是因为主键唯一标识一行——按名字之类的字段删可能误删多行（dept 表的 name 上虽然有唯一约束，但业务上”按 ID 操作”是标准做法：定位精准、不怕重复）； ② 说明 @RequestParam 的 required 默认为 true：一旦加了注解，这个参数就成了必填，缺失时 SpringMVC 在调用方法前就返回 400；不加注解时参数可以缺省（取到 null），错误被悄悄吞掉（Updates: 0）——所以判断”删没删到”要看日志里的影响行数。