Controller 接收参数_controller 带字符串参数-CSDN博客

本文链接：https://blog.csdn.net/2401_86968005/article/details/149510597

Controller 接收参数

原始方式：通过 HttpServletRequest 获取参数

基本用法与原理

核心对象：HttpServletRequest 是 Java EE 赋予我们的一个功能强大的“数据收纳箱”，它将 HTTP 请求所携带的所有数据，如请求参数、请求头信息以及完整的 URL 等细节，统统封装在内。就好比一个装满各种文件的文件夹，我们可以从里面找到所有与请求相关的资料。
获取参数方法：从这个“收纳箱”中获取特定参数的方法很明确，通过 request.getParameter("参数名") 即可。这里的“参数名”就是我们想要获取的参数在前端传递时所使用的名称，该方法会返回对应的参数值，而且统一为 String 类型。这就像是在文件夹中找到特定的文件，并且这份文件的格式是固定的。
示例（删除部门）：

@RestController
@RequestMapping("/depts")
public class DeptController {

    // 删除部门（使用HttpServletRequest接收参数）
    @DeleteMapping
    public Result delete(HttpServletRequest request) {
        // 1. 获取前端传递的id参数（String类型）
        String idStr = request.getParameter("id");
        // 2. 手动转换为int类型（需处理格式错误异常）
        int id = Integer.parseInt(idStr);

        // 3. 执行删除逻辑（此处省略）
        System.out.println("删除部门，id：" + id);

        // 4. 返回成功响应
        return Result.success();
    }
}

在这段代码中，首先通过 request.getParameter("id") 获取到前端传递的 id 参数，此时它是 String 类型。然后，为了能在后续的业务逻辑中正确使用这个参数，需要手动将其转换为 int 类型，这一步需要格外小心，因为如果前端传递的 id 不是一个合法的数字字符串，就会抛出 NumberFormatException 异常。
不推荐方式：虽然通过 HttpServletRequest 对象可以获取请求参数，但这种方式比较繁琐，而且每次都需要手动进行类型转换，容易出错。所以在实际开发中，一般不推荐使用这种方式。

缺点与局限性

代码繁琐：当我们的业务逻辑涉及多个参数时，就需要多次手动调用 getParameter() 方法。想象一下，如果一个表单有十个参数，那就得写十次这样的代码，不仅冗长，还容易出错，就像要重复做十次同样的机械劳动，既枯燥又容易失误。
类型转换麻烦：由于通过 getParameter() 获取的参数都是 String 类型，而实际业务中我们可能需要 int、long 等其他类型的参数。这就要求我们手动进行类型转换，并且在转换过程中还可能因为前端传递的数据格式不正确而抛出 NumberFormatException 异常。例如，前端不小心传递了一个非数字的字符串作为 int 类型参数，就会导致程序出错。这就好比我们收到的货物包装都是一种固定的样式，但我们实际使用时需要不同样式的包装，就不得不手动去转换，而且转换过程中还可能出现损坏货物的风险。
侵入性强：使用这种方式，Controller 的方法必须依赖 HttpServletRequest 对象，这使得代码与 Servlet API 的耦合度较高。这意味着我们的代码在很大程度上依赖于 Servlet 容器的环境，如果未来需要切换到其他环境，可能会面临较大的代码修改成本。就像我们的房子紧紧地依靠着一面墙建造，一旦这面墙出现问题或者我们想换个地方重建房子，就会遇到很多麻烦。
不推荐场景：鉴于以上种种缺点，这种方式在实际开发中除了用于学习理解参数获取的基本原理外，几乎不会被采用。因为它效率低下且容易引入错误，就像驾驶一辆老旧且故障频发的汽车，虽然能勉强行驶，但速度慢且不安全，不如选择更高效可靠的交通工具。

注解方式：@RequestParam——简化参数接收

基本用法与参数绑定

语法格式：使用时非常简单，只需在方法形参前添加 @RequestParam("参数名") 即可，这里的“参数名”就是前端传递参数时使用的名称。通过这种方式，Spring 框架会自动将前端传递的参数值赋给对应的形参。这就像给传送带设置了一个明确的目标地点，货物会准确无误地被送到那里。
@RequestParam 自动类型转换：使用 @RequestParam 注解的一个很大的优势就是它能自动完成数据类型转换。我们无需手动操作，系统会根据参数值和目标类型自动进行转换。例如，前端传递的 id 参数值虽然在请求中是字符串形式，但在方法中我们可以直接使用 int 类型的 deptId 来接收，系统会自动将其转换为 int 类型。这一特性极大地简化了开发流程，减少了手动类型转换可能带来的错误。
@RequestParam 与 HttpServletRequest 对比：@RequestParam 注解直接将前端请求参数绑定到方法形参，使用步骤相对简单，只需要在方法形参前添加注解并指定参数名即可。而使用 HttpServletRequest 则需要手动获取参数并进行类型转换。例如，从使用 HttpServletRequest 方式切换到 @RequestParam 方式，我们只需要复制代码，注释掉旧的获取参数代码，然后添加 @RequestParam 注解绑定参数就可以了。通过 IDE 的快捷键（如 Ctrl + C 和 Ctrl + V）可以快速实现代码复用。在实际应用场景中，@RequestParam 注解通常用于替代 HttpServletRequest 手动获取参数的方式，使代码更加简洁、易读。
示例（删除部门优化）：

@DeleteMapping
public Result delete(
    @RequestParam("id") int id // 直接接收id参数，自动绑定并转换为int
) {
    // 执行删除逻辑
    System.out.println("删除部门，id：" + id);
    return Result.success();
}

在这个优化后的代码中，通过 @RequestParam("id")，Spring 框架自动将前端传递的 id 参数绑定到 id 形参上，并且神奇地将其从 String 类型自动转换为 int 类型。与之前使用 HttpServletRequest 的方式相比，代码量大幅减少，看起来简洁明了，就像经过精心整理的书架，一目了然。
6. 优势：通过对比可以发现，使用 @RequestParam 注解，代码量减少了大约 50%，同时避免了手动获取参数和类型转换的繁琐操作，大大提高了开发效率，降低了出错的可能性。

自动类型转换优势

核心特性：@RequestParam 注解拥有一项非常贴心的特性，它能够根据方法形参所期望的类型，自动将前端传递过来的 String 类型请求参数转换为目标类型。无论是基本类型，如 int、long、boolean，还是它们对应的包装类型，都能轻松应对。这就像有一个智能的翻译官，能够根据我们的需求，自动将不同语言的信息准确地翻译成我们能理解的语言。
支持的转换：它支持多种类型的转换，比如可以将字符串 "123" 自动转换为 int 类型的 123，将字符串 "true" 自动转换为 boolean 类型的 true，还能将字符串 "456" 转换为 Integer 包装类型的 456。这些转换操作都由框架自动完成，我们无需再手动调用 Integer.parseInt() 等转换方法，极大地减少了代码量，同时也避免了因手动转换而可能产生的异常。这就好比有了一个自动化的生产线，能够自动将原材料加工成我们需要的成品，既高效又可靠。
好处：这种自动类型转换的特性，让我们能够更加专注于业务逻辑的实现，而无需花费大量精力在繁琐的类型转换上。同时，由于减少了手动转换的代码，代码的可读性和可维护性也得到了显著提升。就像我们从繁琐的体力劳动中解放出来，能够把更多的精力投入到更有创造性的工作中。

核心属性详解

value属性：当请求参数名与方法形参名不同时，value 属性就显得尤为重要，它用于指定要绑定的请求参数名。例如：

// 前端传递参数名为"deptId"，方法形参名为"id"，需指定value
@DeleteMapping
public Result delete(@RequestParam(value = "deptId") int id) {
    //...
}

在这个例子中，前端传递的参数名为 deptId，而我们在方法中使用的形参名为 id，通过 @RequestParam(value = "deptId")，Spring 框架就知道要将前端传递的 deptId 参数绑定到 id 形参上。这就好比给两个不同名字但实际上代表同一事物的东西建立了一个联系，让它们能够正确对接。
2. @RequestParam 的 required 属性：@RequestParam 注解的作用之一是标记方法参数必须从请求中获取。其 required 属性默认值为 true，这意味着该参数是强制要求传递的。当 required = true 时，如果前端未传递该参数，程序会报错。如果我们希望某个参数是可选的，可以将 required 属性改为 false。
required属性：required 属性主要用于控制参数是否为“必传项”，它的默认值为 true。
- required = true（默认）：当 required 为 true 时，前端在发送请求时必须传递该参数，否则服务器会返回 HTTP 400 Bad Request 错误。这就好比我们去商店买东西，某些商品是必须购买的，没有这些商品，交易就无法完成。
- required = false：如果将 required 设置为 false，则表示该参数为可选参数，前端可以选择传递也可以不传递。当未传递时，参数值为 null，此时为了避免空指针异常，形参需要使用包装类型。例如：

// 可选参数（前端可传可不传）
@GetMapping
public Result query(@RequestParam(value = "name", required = false) String name) {
    System.out.println("查询名称：" + name); // 未传递时name为null
    return Result.success();
}

在这个例子中，name 参数是可选的。如果前端没有传递 name 参数，name 的值就是 null，我们可以在方法中根据这个值进行相应的处理。这就好比去商店买东西，有些商品是可买可不买的，买不买都不会影响交易的进行。

简化写法：请求参数名与方法形参名称相同省略 @RequestParam

规则：当前端请求参数名与 Controller 方法的形参名完全一致时，@RequestParam 注解可以省略不写。Spring 框架会自动识别并将前端传递的参数绑定到对应的形参上。这就像两个人约定好了一个暗号，只要暗号相同，就知道对方的意思，无需再多费口舌。
示例：

// 前端传递参数名为"id"，方法形参名也为"id"，省略@RequestParam
@DeleteMapping
public Result delete(int id) { 
    // 等价于@RequestParam("id") int id
    //...
}

在这个示例中，前端传递的参数名和方法形参名都为 id，此时我们可以省略 @RequestParam 注解，代码看起来更加简洁明了。这就好比我们简化了一个复杂的操作流程，让代码更加清爽，提高了代码的可读性。
3. 优势：这种简化写法进一步减少了代码中的注解冗余，使代码更加简洁易懂，推荐在参数名一致的情况下使用。就像给代码做了一次精简的美容，让它看起来更加美观大方，同时也方便其他开发人员阅读和维护。
4. 推荐方式：保持请求参数名与方法形参名一致是一种非常简洁的开发方式，它不仅减少了代码量，还使代码更加清晰易读。我们可以通过故意修改形参名与请求参数名不一致来验证这种自动绑定机制。例如，将 orderId 形参改为 id，此时如果不使用 @RequestParam 注解，就无法正确接收参数，从而验证了只有参数名一致时才会自动绑定。需要注意的是，当参数名不一致时，必须显式使用 @RequestParam 注解来指定参数名。

不同方式对比与最佳实践

接收方式	优点	缺点	适用场景
HttpServletRequest	兼容所有 Java EE 环境，获取请求细节全面	代码繁琐，需手动转换类型，耦合度高	学习理解原理，或需要获取完整请求信息时
@RequestParam 注解	代码简洁，自动类型转换，低耦合	仅适用于 Spring 环境	绝大多数场景（推荐使用）

结论

HttpServletRequest 是一种比较原始的参数接收方式，虽然它能全面获取请求细节，并且兼容所有 Java EE 环境，但由于需要手动处理参数，代码繁琐且容易出错，一般只适合用于学习理解参数获取的基本原理。
@RequestParam 注解是 Spring 框架推荐的参数接收方式，它通过简洁的注解形式，实现了参数的自动绑定，并且支持灵活的类型转换和可选参数设置。在绝大多数情况下，使用它可以显著提高开发效率，让代码更加简洁易读。
当请求参数名与形参名一致时，省略 @RequestParam 注解能够进一步简化代码，使代码更加简洁明了，这是一种值得推荐的写法。

常见问题

报错“Required parameter ‘id’ is not present”：
- 原因：这是因为 @RequestParam 注解默认 required = true，即该参数是必传的，但前端在发送请求时没有传递这个参数。就好比我们去参加一个活动，活动规定必须携带某个物品，但我们忘记带了，就会被拒绝入场。
- 解决：如果这个参数确实是必须传递的，那么前端需要确保在请求中传递该参数。如果该参数是可选的，我们可以在 @RequestParam 注解中设置 required = false，告诉框架这个参数可以不传递。这就好比活动组织者考虑到有些人可能不方便携带那个物品，就放宽了规定，允许不带。
类型转换异常“NumberFormatException”：
- 原因：前端传递的参数值无法转换为目标类型，比如前端传递了一个非数字的字符串，却期望后端将其转换为 int 类型。这就好比我们要把一个方形的物品放进圆形的洞里，肯定是放不进去的。
- 解决：前端在传递参数时，要确保参数的格式正确，符合后端的期望。后端也可以添加参数校验逻辑，对前端传递过来的参数进行格式检查，一旦发现格式不正确，及时返回错误提示给前端，告知用户正确的参数格式。这就好比我们在洞旁边设置了一个标识，告诉人们只有圆形的物品才能放进去，同时也检查放进去的物品是否符合要求。
参数名与形参名不同导致接收失败：
- 原因：当请求参数名与形参名不同时，如果没有通过 @RequestParam 的 value 属性指定参数名，Spring 框架就无法正确地将前端参数绑定到形参上，从而导致接收失败。这就好比两个人互相不认识，又没有中间人介绍，就无法建立有效的沟通。
- 解决：在这种情况下，我们需要在 @RequestParam 注解中显式地通过 value 属性指定参数名，例如 @RequestParam("deptId") int id，这样 Spring 框架就能明白要将前端传递的 deptId 参数绑定到 id 形参上，确保参数接收成功。这就好比找到了一个中间人，让他介绍这两个人认识，从而建立起沟通的桥梁。