一、报错核心含义解析
Request method 'GET' not supported 是若依（RuoYi）框架基于 Spring MVC 抛出的请求方法不支持异常 ，核心含义是：你发起的GET 请求 访问了某接口，但该接口在后端仅配置了支持 POST/PUT/DELETE 等其他请求方法（如 @PostMapping），Spring MVC（若依底层）检测到请求方法与接口定义的方法不匹配，因此返回405 Method Not Allowed错误，并提示 "GET 方法不被支持"。
简单来说：前端用 GET 方式调用了一个仅允许 POST（或其他）请求的若依接口，前后端请求方法不匹配导致报错。
二、典型判断
看到该报错可立刻做出以下核心判断：
- 根因是「请求方法不匹配」 ：后端接口通过
@PostMapping/@PutMapping等注解限定了请求方法，前端却用了 GET，是最核心的原因； - 错误属于「客户端请求错误（405 状态码）」：非服务端代码 bug，而是请求方式不符合接口约定；
- 若依框架场景特征：该报错常出现在新增 / 修改 / 删除操作（若依默认用 POST）、前端接口调用代码写错请求方法、后端注解配置错误这三类场景；
- 需重点核对「接口 URL」和「请求方法」：找到报错的 URL，对比后端控制器的注解和前端的请求方式即可定位问题。
三、若依框架下的典型错误场景
结合若依的使用规范，触发该报错的核心场景如下：
场景 1：后端接口用@PostMapping，前端用 GET 请求（最常见）
若依框架中，新增 / 修改 / 删除类接口默认用 @PostMapping，查询类用 @GetMapping，若前端误将 POST 请求写成 GET，会直接报错。❌ 错误示例：
-
后端控制器（若依生成的 SysUserController）： java
运行
@RestController @RequestMapping("/system/user") public class SysUserController { // 新增用户：仅支持POST请求 @PostMapping("/add") public AjaxResult addSave(@Validated @RequestBody SysUser user) { return userService.insertUser(user); } } -
前端接口调用（若依 vue 前端）： js
// 错误：用get请求调用仅支持POST的/add接口 export function addUser(data) { return request({ url: '/system/user/add', method: 'get', // 应为post params: data }) }
场景 2：后端@RequestMapping未指定 method，后续修改为限定方法但前端未同步
初期后端用@RequestMapping("/list")（默认支持所有请求方法），后续改为@PostMapping("/list")，但前端仍用 GET 请求该接口。❌ 错误示例：
java
运行
// 初期：支持所有方法
@RequestMapping("/list")
// 后期修改为仅支持POST，前端未同步
@PostMapping("/list")
public TableDataInfo list(SysUser user) { ... }场景 3：前端误将 "参数传递方式" 和 "请求方法" 混淆
若依前端中，GET 请求用params传参，POST 请求用data传参，部分开发者为了传参方便，将 POST 接口改为 GET+params，导致方法不匹配。❌ 错误示例：
js
// 接口应为POST+data传参，却改成GET+params
export function saveUser(data) {
return request({
url: '/system/user/save',
method: 'get', // 错误：应为post
params: data // POST应改用data: data
})
}场景 4：若依代码生成器生成的接口，手动修改了请求方法注解
若依代码生成器会根据 "查询 / 新增 / 修改 / 删除" 自动生成对应注解（查询 @GetMapping，操作 @PostMapping），若手动将@PostMapping改成@PutMapping，但前端仍用 POST/GET，会触发报错。
场景 5：静态资源 / 页面请求方法错误（少见）
访问若依的静态页面（如 /login）时，前端请求方法误设为 POST，或后端对静态资源接口限定了方法，导致 GET 访问被拒绝。
四、处理办法（结合若依框架实操）
步骤 1：定位报错的接口 URL 和请求方法
- 前端排查：打开浏览器 F12→Network，找到报错的请求，查看「Request URL」和「Request Method」（显示为 GET）；
- 后端排查 ：查看若依的日志（默认在
logs/ruoyi.log），找到包含Request method 'GET' not supported的日志行，日志中会显示请求的 URL（如/system/user/add）。
步骤 2：核对后端控制器的请求方法注解
找到该 URL 对应的后端控制器方法，查看注解：
- 若注解是
@PostMapping/@PutMapping/@DeleteMapping，说明接口仅支持对应方法； - 若注解是
@GetMapping，说明接口仅支持 GET（此时若前端用 POST 会报Request method 'POST' not supported）。
步骤 3：修正前后端不匹配的问题（核心）
**情况 1：后端注解正确，前端请求方法错误（90% 的场景）**修改前端请求方法，匹配后端注解：
js
// 正确示例：POST请求+data传参（若依POST接口标准写法）
export function addUser(data) {
return request({
url: '/system/user/add',
method: 'post', // 改为post
data: data // POST用data传参，GET用params
})
}情况 2：前端请求方法正确，后端注解错误修改后端注解，匹配前端请求方法（需遵循若依规范）：
- 查询接口：用
@GetMapping； - 新增 / 修改 / 删除接口：用
@PostMapping；
java
运行
// 若前端用GET请求/list，后端应改为@GetMapping
@GetMapping("/list")
public TableDataInfo list(SysUser user) { ... }情况 3：需要支持多种请求方法 若需接口同时支持 GET 和 POST，用@RequestMapping并指定 method：
java
运行
@RequestMapping(value = "/list", method = {RequestMethod.GET, RequestMethod.POST})
public TableDataInfo list(SysUser user) { ... }步骤 4：验证修复结果
- 前端重新调用接口，查看浏览器 Network：请求方法为匹配的 POST/GET，状态码 200；
- 后端日志无
Request method 'GET' not supported报错，接口正常返回数据。
五、若依框架下的避免方式
-
遵循若依的请求方法规范
- 严格按若依默认约定：查询类接口用 GET（@GetMapping），新增 / 修改 / 删除用 POST（@PostMapping）；
- 若需用 PUT/DELETE，需前后端同步约定（若依前端 request.js 已封装 put/delete 方法）。
-
前端统一使用若依封装的请求方法 若依前端
src/utils/request.js已封装 get/post/put/delete 方法，直接调用避免手写错误：js
// 推荐：用封装的方法，语义更清晰 import { get, post, put, del } from '@/utils/request' // 查询列表（GET） export function getUserList(params) { return get('/system/user/list', params) } // 新增用户（POST） export function addUser(data) { return post('/system/user/add', data) } -
接口开发前前后端约定请求方法新增接口时，先在接口文档（若依自带接口文档）中明确请求方法，前端按文档开发，避免后期修改不一致。
-
代码生成后不随意修改注解若依代码生成器生成的控制器注解（@GetMapping/@PostMapping），非必要不修改；若修改，需同步通知前端调整请求方法。
-
接口测试先通过 Postman 验证后端接口开发完成后，先用 Postman 测试：用对应方法（GET/POST）访问接口，确认返回正常，再交给前端联调。