亲爱的小伙伴们😘，在求知的漫漫旅途中，若你对深度学习的奥秘、Java 与 Python 的奇妙世界，亦或是读研论文的撰写攻略有所探寻🧐，那不妨给我一个小小的关注吧🥰。我会精心筹备，在未来的日子里不定期地为大家呈上这些领域的知识宝藏与实用经验分享🎁。每一个点赞👍，都如同春日里的一缕阳光，给予我满满的动力与温暖，让我们在学习成长的道路上相伴而行，共同进步✨。期待你的关注与点赞哟🤗！
在 Spring 框架的 Web 开发领域，请求注解扮演着至关重要的角色。它们就像是一把把钥匙，开启了客户端与服务器端交互的大门，使得开发者能够便捷、高效地处理各种 HTTP 请求，构建出强大而灵活的 Web 应用程序。今天，我们就来深入探讨一下 Spring 中的各类请求注解，详细了解它们的使用场景、适用范围以及一些需要注意的地方。
一、@RequestMapping
作为 Spring Web 中最基础、最常用的请求注解，@RequestMapping 拥有强大的功能，它可以应用在类级别和方法级别。
类级别使用
当应用在类上时，它为整个控制器类指定了一个基础的 URL 路径。例如：
@RestController
@RequestMapping("/api/v1")
public class UserController {// 类中的方法请求路径都以 /api/v1 开头
}在这个例子中，UserController 下所有带有请求注解的方法，其访问路径都会以 /api/v1 作为前缀，这样做有利于对 API 进行版本管理，将不同版本的接口统一规划在不同的类路径下。
方法级别使用
在方法上，@RequestMapping 可以精确指定 HTTP 请求方法（GET、POST、PUT、DELETE 等）以及具体的 URL 路径。
@RestController
@RequestMapping("/users")
public class UserController {@RequestMapping(value = "/{id}", method = RequestMethod.GET)public User getUserById(@PathVariable("id") Long id) {// 根据 id 查询用户并返回return userService.getUserById(id);}@RequestMapping(value = "/", method = RequestMethod.POST)public User createUser(@RequestBody User user) {// 创建新用户并返回return userService.createUser(user);}
}这里定义了两个方法，一个用于根据用户 ID 获取用户信息（通过 GET 请求），另一个用于创建新用户（通过 POST 请求）。通过 value 属性指定具体的路径片段，method 属性明确请求类型，使得不同的业务逻辑能够清晰地对应到相应的 HTTP 操作。
适用场景：适用于绝大多数需要处理 HTTP 请求的场景，尤其是在构建传统风格的 RESTful API 时，它提供了灵活的配置方式来满足不同的 URL 和请求方法组合需求。
不适用场景：随着 RESTful 架构的越发规范，@RequestMapping 在表达语义上相对较弱，相较于一些专门为特定 HTTP 方法设计的注解，代码的可读性稍差一些。例如，在一个纯粹遵循 RESTful 规范且只涉及标准 HTTP 方法操作的项目中，使用 @RequestMapping 来区分每个方法的请求方式会显得有些繁琐。
二、@GetMapping
@GetMapping 是 @RequestMapping(method = RequestMethod.GET) 的快捷方式，专门用于处理 HTTP GET 请求。
@RestController
@RequestMapping("/books")
public class BookController {@GetMapping("/{id}")public Book getBookById(@PathVariable("id") Long id) {return bookService.getBookById(id);}@GetMapping("/search")public List<Book> searchBooks(@RequestParam String keyword) {return bookService.searchBooks(keyword);}
}上面的代码中，第一个方法用于获取指定 ID 的书籍，第二个方法用于根据关键词搜索书籍，都是典型的 GET 请求场景。使用 @GetMapping 使得代码更加简洁明了，一眼就能看出这些方法是处理 GET 请求的。
适用场景：只要是需要从服务器获取资源，不改变服务器状态的操作，都应该使用 @GetMapping，比如查询数据库记录、获取配置信息、搜索数据等场景。
不适用场景：如果方法需要处理非 GET 请求，如修改数据（对应 PUT 或 POST）、删除数据（对应 DELETE），那么就不能使用 @GetMapping，否则会导致请求无法正确处理，返回 405 Method Not Allowed 错误。
三、@PostMapping
与 @GetMapping 类似，@PostMapping 是用于处理 POST 请求的注解，它将请求映射到特定的处理方法上，通常用于提交数据创建新资源。
@RestController
@RequestMapping("/orders")
public class OrderController {@PostMapping("/")public Order createOrder(@RequestBody Order order) {return orderService.createOrder(order);}
}在这个例子中，客户端通过 POST 请求向 /orders 路径提交订单数据（封装在 Order 对象中），服务器端使用 @PostMapping 注解的方法接收并处理创建订单的逻辑。
适用场景：常用于表单提交、创建新的业务实体，例如用户注册（提交用户信息创建新用户）、新增一篇文章、生成一份订单等场景，只要是向服务器传递数据以创建新内容的操作，基本都用 @PostMapping。
不适用场景：当操作不是创建新资源，而是获取（应该用 @GetMapping）、更新（宜用 @PutMapping 或 @PatchMapping）、删除（要用 @DeleteMapping）资源时，不能使用 @PostMapping，不然会违背 RESTful 设计原则，导致业务逻辑混乱，接口语义不清晰。
四、@PutMapping
@PutMapping 专门用于处理 HTTP PUT 请求，主要目的是更新服务器上的现有资源。
@RestController
@RequestMapping("/products")
public class ProductController {@PutMapping("/{id}")public Product updateProduct(@PathVariable("id") Long id, @RequestBody Product updatedProduct) {return productService.updateProduct(id, updatedProduct);}
}这里客户端向 /products/{id} 发送 PUT 请求，携带更新后的 Product 对象信息，服务器端使用 @PutMapping 注解的方法根据提供的 ID 找到对应的产品，并更新其全部信息。
适用场景：适用于客户端提供完整的资源更新数据，需要完全替换服务器上已有资源状态的情况，比如更新用户的所有信息（包括姓名、年龄、地址等全部字段），或者更新一篇文章的全部内容。
不适用场景：如果只是部分更新资源，@PutMapping 就不太合适。因为它暗示着要替换整个资源，若仅修改个别字段，使用 @PutMapping 可能会导致不必要的数据传输开销，并且容易误操作覆盖掉不想修改的字段。此时更适合用 @PatchMapping。另外，若操作不是更新资源，而是创建（应用 @PostMapping）、查询（使用 @GetMapping）、删除（借助 @DeleteMapping）资源，也不能用 @PutMapping。
五、@PatchMapping
@PatchMapping 用于处理 PATCH 请求，它的设计初衷是为了支持对资源的部分更新。
@RestController
@RequestMapping("/users")
public class UserController {@PatchMapping("/{id}")public User partialUpdateUser(@PathVariable("id") Long id, @RequestBody Map<String, Object> updates) {return userService.partialUpdateUser(id, updates);}
}在这个示例中，客户端向 /users/{id} 发送 PATCH 请求，请求体中只包含需要修改的用户信息字段（以 Map 形式），服务器端的方法就能针对性地更新指定用户的部分属性，避免像 @PutMapping 那样更新整个用户对象，节省带宽和避免数据丢失风险。
适用场景：在需要对资源进行局部修改的场景中大放异彩，比如只更新用户的密码、修改订单的状态、更新文章的标题等，凡是不需要替换整个资源，只需调整个别或几个关键属性的情况，都优先考虑 @PatchMapping。
不适用场景：如果客户端要更新资源的全部信息，从语义和效率角度考虑，更应该用 @PutMapping；而对于创建、查询、删除资源的操作，显然 @PatchMapping 是不适用的，会导致请求无法按预期被处理。
六、@DeleteMapping
@DeleteMapping 用于映射 HTTP DELETE 请求，负责删除服务器上指定的资源。
@RestController
@RequestMapping("/tasks")
public class TaskController {@DeleteMapping("/{id}")public void deleteTask(@PathVariable("id") Long id) {taskService.deleteTask(id);}
}这里客户端向 /tasks/{id} 发送 DELETE 请求，服务器端使用 @DeleteMapping 注解的方法根据传入的任务 ID，调用服务层方法从数据库或其他存储介质中删除对应的任务记录。
适用场景：当需要从服务器移除某个资源时，如删除用户账户、清除过期的日志文件、作废某个订单等场景，毫无疑问要使用 @DeleteMapping，以确保操作与 HTTP 语义中的删除行为一致。
不适用场景：除了删除资源之外的操作，像获取资源详情（应用 @GetMapping）、创建新资源（使用 @PostMapping）、更新资源（采用 @PutMapping 或 @PatchMapping）都不能使用 @DeleteMapping，否则会让客户端和服务器端的交互逻辑混乱不堪，无法达成预期的业务目标。
七、请求注解的组合使用与注意事项
在实际项目开发中，往往会灵活组合使用这些请求注解。比如在一个复杂的电商系统后台管理模块，可能既有查询商品列表（@GetMapping("/products")），又有根据条件筛选商品（@GetMapping("/products/search")），还有创建新商品（@PostMapping("/products")）、更新商品信息（@PutMapping("/products/{id}")）以及下架商品（@DeleteMapping("/products/{id}")）等操作，不同的请求注解各司其职，构建起完整的业务接口体系。
但在使用过程中，也有一些注意事项：
首先，要严格遵循 RESTful 设计规范，让请求方法与业务操作的语义紧密契合。这样不仅能提升代码的可读性，还便于团队成员理解和维护，同时也能让前后端开发人员基于统一的接口规范高效协作。
其次，对于路径变量（@PathVariable）和请求参数（@RequestParam）的使用要恰当。路径变量常用于从 URL 中提取关键的资源标识，如资源 ID；而请求参数更多用于传递一些查询条件、筛选信息等额外的数据。合理区分它们，能使接口设计更加清晰，避免混淆不同类型的数据来源。
再者，注意请求体（@RequestBody）的使用。通常 POST、PUT、PATCH 等修改或创建资源的请求会用到请求体来接收客户端传来的资源数据，并且要确保客户端发送的数据格式与服务器端接收的对象类型匹配，否则会出现数据解析错误。
注意：
1、如果用@requestBody注解，则请求体内容类型一般要为application/json，如果其类型为multipart/form-data，则会报错：不支持的媒体类型；（实战经验）
2、如果用@requestParam注解，默认必须要传该参数名对应的参数，否则会报错。