前端发起 HTTP 请求时，浏览器 Network 面板频繁出现 404、405、500 等状态码，是前后端交互中最常见的接口异常。这些状态码并非前端代码语法错误，而是 HTTP 协议层面的响应状态提示——404 代表资源未找到，405 代表请求方法不被允许，500 代表服务器内部错误，三类错误的排查方向截然不同：404 侧重「资源路径匹配」，405 侧重「请求方法与跨域配置」，500 侧重「后端代码与服务器环境」。本文将从每个状态码的核心本质出发，分场景梳理高频诱因与解决方案，覆盖前端配置、后端接口、服务器环境、代理转发等全链路，提供可直接落地的排查步骤和代码示例，帮助开发者快速定位并解决问题。
一、核心认知：三类状态码的本质与快速区分
在排查错误前，先明确 404、405、500 的 HTTP 定义和核心差异，避免因混淆状态码含义导致排查方向偏离，这是高效解决问题的基础。
1.1 状态码核心定义与本质
| 状态码 | HTTP 定义 | 核心本质 | 责任方（大概率） | 典型现象 |
|---|---|---|---|---|
| 404 Not Found | 服务器无法找到请求的资源 | 前端请求的「URL 路径/资源」在后端不存在，或路径匹配失败 | 前端（地址错误）/ 后端（路由未配置） | 接口无响应，返回'资源不存在'，Network 面板请求状态为 404 |
| 405 Method Not Allowed | 服务器支持当前 URL，但不支持请求使用的 HTTP 方法 | 前端使用的请求方法（GET/POST/PUT/DELETE）与后端接口定义的方法不匹配，或跨域预检未处理 | 前端（方法错误）/ 后端（跨域/接口配置） | 接口返回'方法不允许'，跨域场景下常伴随 OPTIONS 预检请求 405 |
| 500 Internal Server Error | 服务器执行请求时发生未捕获的内部错误 | 后端代码逻辑错误、数据库异常、依赖服务故障等导致服务器崩溃 | 后端（代码/环境） | 接口无正常响应，返回'服务器内部错误'，Network 面板请求状态为 500，后端日志有报错 |
1.2 快速区分：通过 Network 面板定位状态码类型
打开浏览器 F12 → Network 面板，找到报红的请求，通过以下 3 点快速区分状态码类型，无需查看后端日志：
- Status 列：直接显示状态码（404/405/500）；
- Request Method 列：查看请求方法（GET/POST 等），辅助判断 405；
- Response/Preview 列：查看后端返回的错误信息（如'404 Not Found''500 Internal Server Error'），进一步确认错误类型。
1.3 关键前提：明确'请求是否到达后端'
三类状态码的排查核心差异在于「请求是否到达后端」，这是区分责任方的关键：
- 404：可能未到达后端（前端地址错误），也可能到达后端但路由未匹配；
- 405：已到达后端（服务器识别 URL 但拒绝方法）；
- 500：已到达后端（服务器执行代码时出错）。
二、场景 1:404 Not Found（资源未找到）—— 排查与解决方案
404 是最常见的接口异常，核心排查方向是「前端请求地址是否正确」和「后端路由是否配置匹配」，以下梳理 6 个高频场景，覆盖前端、后端、代理全链路。
2.1 场景 1.1：前端请求地址拼写错误（最高频）
错误表现
前端 Axios/Fetch 请求的 URL 路径拼写错误（如多写斜杠、少写单词、大小写错误），导致请求地址无效，后端无对应路由。
错误示例（前端）
// 错误 1：多写斜杠（后端接口为/api/user，前端写为/api//user）
axios.get('/api//user')
// 错误 2：少写单词（后端接口为/api/user/list，前端写为/api/user/lst）
axios.get('/api/user/lst')
// 错误 3：大小写敏感（后端路由为/api/User，前端写为/api/user，Linux 服务器下会 404）
axios.get('/api/user')
// 错误 4：端口错误（后端服务运行在 3000 端口，前端写为 8080）
axios.get('http://localhost:8080/api/user')
核心原因
前端请求的 URL 路径、端口、大小写与后端接口定义不一致，导致请求未匹配到任何后端路由。
解决方案
- 严格核对请求地址：与后端接口文档（如 Swagger）逐一核对 URL 路径、端口、大小写，确保完全一致；
- 注意大小写敏感：Linux 服务器（如 Nginx、Node.js）对 URL 路径大小写敏感，Windows 服务器不敏感，开发时统一使用小写路径，与后端保持一致。
统一全局 baseURL：前端配置 Axios 全局 baseURL，避免单个请求硬编码地址，减少拼写错误：
// 正确：全局配置 baseURL，单个请求仅写接口后缀
const service = axios.create({
baseURL: 'http://localhost:3000/api'
})
service.get('/user')
// 实际请求地址：http://localhost:3000/api/user
2.2 场景 1.2：后端路由配置错误/未配置
错误表现
前端请求地址正确，但后端未配置对应路由，或路由路径、请求方法不匹配（如后端路由为 POST，前端用 GET 请求，部分后端框架会返回 404 而非 405）。
错误示例（后端）
// Node.js/Express 错误：路由路径与前端请求不匹配（前端请求/api/user，后端为/api/users）
app.get('/api/users', (req, res) => {
res.json({ code: 200, data: '用户数据' })
})
// Java/SpringBoot 错误：路由路径少写前缀（前端请求/api/user，后端为/user）
@RestController
@RequestMapping("/")
public class UserController {
@GetMapping("/user")
public Result getUser() {
return Result.success("用户数据");
}
}
核心原因
后端路由路径、前缀、请求方法与前端请求不匹配，导致服务器无法找到对应资源。
解决方案
- 后端核对路由配置：
- 检查路由路径是否与前端请求一致（含前缀，如/api）；
- 检查路由对应的请求方法是否与前端一致（如前端 GET，后端是否为 GET）；
- 后端提供接口文档：通过 Swagger 等工具生成接口文档，明确 URL、方法、参数，避免前后端不一致；
后端返回详细 404 信息：在后端全局异常处理中，返回具体的路由匹配失败信息，方便排查：
// Express 全局 404 处理
app.use((req, res) => {
res.status(404).json({
code: 404,
msg: `资源未找到：${req.method}${req.originalUrl}，请检查请求地址和方法`
})
})
2.3 场景 1.3：前端代理配置错误（本地开发）
错误表现
本地开发时配置了前端代理（如 Vite/Vue 的 proxy），但代理的 target 地址、路径重写错误，导致请求被转发到无效地址，返回 404。
错误示例（前端代理配置）
// Vite 错误配置：target 地址错误（后端服务运行在 3000 端口，代理写为 3001）
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'http://localhost:3001', // 错误：后端端口为 3000
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '')
}
}
}
})
核心原因
代理配置的 target 地址（后端真实地址）错误，或 pathRewrite 路径重写错误，导致请求转发到无效地址，后端无对应资源。
解决方案
- 核对代理配置：
- target：确保为后端服务的真实地址（协议+IP+端口）；
- pathRewrite：确保路径重写规则正确（如后端接口无/api前缀，前端代理需去掉/api）；
- 验证代理是否生效：查看 Network 面板的 Request URL，确认请求地址为前端本地代理地址（如 http://localhost:8080/api/user），而非后端真实地址。
正确配置示例（Vite）：
export default defineConfig({
server: {
proxy: {
'/api': {
target: 'http://localhost:3000', // 后端真实地址
changeOrigin: true,
rewrite: (path) => path.replace(/^\/api/, '') // 前端请求/api/user → 后端/user
}
}
}
})
2.4 场景 1.4：后端接口未部署/资源未发布
错误表现
前端请求的接口已在本地开发环境测试通过，但线上环境返回 404，原因是后端接口未部署到线上服务器，或资源（如静态文件）未发布。
核心原因
线上服务器未部署对应后端服务，或部署的服务版本中无该接口（如遗漏提交代码、部署错误版本）。
解决方案
- 后端确认接口已部署：检查线上服务器的后端服务是否启动，是否部署了包含该接口的版本；
- 验证线上接口地址：通过 Postman/curl 直接访问线上接口地址（如 https://api.xxx.com/api/user），确认是否返回 404；
- 检查静态资源路径：若请求的是静态资源（如图片、文件），确认资源已上传到服务器，且路径配置正确。
2.5 场景 1.5：跨域预检请求 404（特殊场景）
错误表现
跨域场景下，前端发送 OPTIONS 预检请求后返回 404，导致实际请求无法发起，表现为前端控制台报跨域错误，Network 面板显示 OPTIONS 请求 404。
核心原因
后端未配置跨域支持，或未处理 OPTIONS 预检请求，导致服务器将 OPTIONS 请求视为普通请求，未匹配到对应路由，返回 404。
解决方案
后端配置 CORS 跨域支持，允许 OPTIONS 预检请求，示例如下（Node.js/Express）：
// 全局 CORS 中间件，处理 OPTIONS 预检请求
app.use((req, res, next) => {
res.header('Access-Control-Allow-Origin', 'http://localhost:8080')
res.header('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE,OPTIONS')
res.header('Access-Control-Allow-Headers', 'Token,Content-Type')
// 预检请求直接返回 200
if (req.method === 'OPTIONS') {
return res.sendStatus(200)
}
next()
})
2.6 场景 1.6：Nginx 反向代理路径配置错误（线上环境）
错误表现
线上环境通过 Nginx 反向代理转发接口请求，但 Nginx 的 location 路径配置错误，导致请求无法转发到后端服务，返回 404。
错误示例（Nginx 配置）
server {
listen 80;
server_name api.xxx.com;
# 错误：location 路径为/api，但后端接口无/api前缀，且未重写路径
location /api {
proxy_pass http://localhost:3000; # 后端接口为 http://localhost:3000/user，而非/api/user
}
}
核心原因
Nginx 的 location 路径与后端接口路径不匹配，或未配置路径重写，导致请求转发到无效地址。
解决方案
修改 Nginx 配置，确保路径转发正确，示例如下：
server {
listen 80;
server_name api.xxx.com;
# 正确 1：location 路径为/api，重写路径去掉/api前缀
location /api/ {
proxy_pass http://localhost:3000/; # 末尾/必须加
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 正确 2：location 路径为/，直接转发所有请求（后端接口有/api前缀）
# location / {
# proxy_pass http://localhost:3000;
# }
}
三、场景 2:405 Method Not Allowed（方法不允许）—— 排查与解决方案
405 状态码的核心是「请求方法不匹配」或「跨域预检未处理」，排查方向集中在「前端请求方法」「后端接口方法配置」「跨域 CORS 配置」三点，以下梳理 4 个高频场景。
3.1 场景 2.1：前端请求方法与后端接口方法不匹配（最高频）
错误表现
前端使用 GET 请求后端 POST 接口，或使用 PUT 请求后端 DELETE 接口，导致服务器拒绝该方法。
错误示例
// 前端错误：用 GET 请求后端 POST 接口（后端接口为 POST /api/user/add）
axios.get('/api/user/add', { data: { username: 'test' } })
// 后端 Node.js/Express 接口（POST 方法）
app.post('/api/user/add', (req, res) => {
res.json({ code: 200, msg: '新增成功' })
})
核心原因
前端请求方法与后端接口定义的方法不一致，服务器识别 URL 有效但拒绝该方法。
解决方案
- 核对前后端请求方法：与后端接口文档核对，确保前端使用的方法（GET/POST/PUT/DELETE）与后端一致；
后端返回方法允许信息：在后端全局异常处理中，返回允许的请求方法，方便排查：
// Express 405 异常处理
app.use((req, res) => {
// 获取该路由允许的方法（需后端框架支持）
const allowedMethods = ['POST']
res.status(405).json({
code: 405,
msg: `方法不允许：${req.method}${req.originalUrl}，允许的方法：${allowedMethods.join(',')}`
})
})
正确示例（前端）：
// 后端为 POST 接口，前端用 POST 请求
axios.post('/api/user/add', { username: 'test' })
3.2 场景 2.2：跨域预检请求 OPTIONS 被后端拒绝（高频）
错误表现
跨域场景下，前端发送 OPTIONS 预检请求后返回 405，导致实际请求（GET/POST）无法发起，控制台报跨域错误。
核心原因
后端配置 CORS 时，未允许 OPTIONS 方法，或未正确处理预检请求，导致服务器拒绝 OPTIONS 方法，触发 405。
解决方案
后端配置 CORS 时，明确允许 OPTIONS 方法，并对 OPTIONS 请求直接返回 200，示例如下（Java/SpringBoot）：
@Configuration
public class CorsConfig implements WebMvcConfigurer {
@Override
public void addCorsMappings(CorsRegistry registry) {
registry.addMapping("/**")
.allowedOrigins("http://localhost:8080")
.allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") // 必须包含 OPTIONS
.allowedHeaders("Token", "Content-Type")
.allowCredentials(true)
.maxAge(3600);
}
}
3.3 场景 2.3：后端接口未开放对应请求方法
错误表现
后端接口仅开放 GET 方法，但前端使用 POST 方法，或后端未配置该方法的路由，导致 405。
错误示例（后端）
// Node.js/Express 错误：仅配置 GET 方法，前端用 POST 请求
app.get('/api/user/update', (req, res) => {
res.json({ code: 200, msg: '更新成功' })
})
核心原因
后端接口未配置前端使用的请求方法，或仅开放了部分方法（如仅 GET）。
解决方案
- 后端明确接口支持的方法：在接口文档中注明支持的请求方法，避免前端误用。
后端添加对应方法的路由：
// 正确：配置 POST 方法，或同时支持 GET/POST
app.post('/api/user/update', (req, res) => {
res.json({ code: 200, msg: '更新成功' })
})
// 或同时支持多种方法
app.all('/api/user/update', (req, res) => {
if (['GET', 'POST'].includes(req.method)) {
res.json({ code: 200, msg: '更新成功' })
} else {
res.status(405).json({ msg: '方法不允许' })
}
})
3.4 场景 2.4：Nginx 禁止特定请求方法
错误表现
线上环境通过 Nginx 反向代理，Nginx 配置禁止了前端使用的请求方法（如 POST），导致返回 405。
错误示例（Nginx 配置）
server {
listen 80;
server_name api.xxx.com;
# 错误：禁止 POST 方法
if ($request_method !~ ^(GET|HEAD|OPTIONS)$) {
return 405;
}
location /api/ {
proxy_pass http://localhost:3000/;
}
}
核心原因
Nginx 配置了 $request_method 限制，禁止了前端使用的请求方法（如 POST）。
解决方案
修改 Nginx 配置，允许前端使用的请求方法，示例如下：
server {
listen 80;
server_name api.xxx.com;
# 正确：允许 GET/POST/PUT/DELETE/OPTIONS 方法
if ($request_method !~ ^(GET|POST|PUT|DELETE|OPTIONS)$) {
return 405;
}
location /api/ {
proxy_pass http://localhost:3000/;
}
}
四、场景 3:500 Internal Server Error（服务器内部错误）—— 排查与解决方案
500 状态码的责任方几乎全在后端，核心排查方向是「后端代码逻辑」「数据库环境」「服务器配置」，前端仅需辅助提供请求信息，以下梳理 5 个高频场景。
4.1 场景 3.1：后端代码逻辑错误（最高频）
错误表现
后端代码存在语法错误、空指针异常、逻辑漏洞等，导致执行请求时抛出未捕获的异常，服务器返回 500。
错误示例（后端）
// Node.js/Express 错误：未判断数据是否存在，导致空指针
app.get('/api/user/:id', (req, res) => {
const userId = req.params.id
// 错误：未判断 user 是否为 null，若查询不到用户，user 为 null，user.name 会报错
const user = db.query('SELECT * FROM user WHERE id = ?', userId)
res.json({ code: 200, data: { name: user.name } })
})
// Java/SpringBoot 错误：数组越界异常
@GetMapping("/api/list")
public Result getList() {
List<String> list = new ArrayList<>();
// 错误：list 为空，get(0) 会抛出 ArrayIndexOutOfBoundsException
String item = list.get(0);
return Result.success(item);
}
核心原因
后端代码未做异常捕获，存在空指针、数组越界、语法错误等问题，导致服务器执行代码时崩溃。
解决方案
- 后端修复代码逻辑：
- 添加空值判断（如
if (!user) return res.status(404).json({ msg: '用户不存在' })）； - 避免数组越界、语法错误等低级问题；
- 添加空值判断（如
- 后端查看错误日志：通过服务器日志（如 Linux 的/var/log、SpringBoot 的 logs 目录）查看具体报错信息（如异常堆栈），定位代码错误位置。
后端添加全局异常捕获：统一处理未捕获的异常，返回友好提示，同时记录详细日志，方便排查：
// SpringBoot 全局异常处理
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(Exception.class)
public Result handleException(Exception e) {
// 记录错误日志（如使用 Logback/Log4j）
log.error("服务器内部错误：", e);
// 返回友好提示
return Result.error("服务器内部错误，请联系管理员");
}
}
4.2 场景 3.2：数据库异常（高频）
错误表现
后端请求数据库时发生异常（如数据库连接失败、SQL 语法错误、表/字段不存在），导致服务器返回 500。
核心原因
- 数据库服务未启动、连接配置错误（如 IP/端口/密码错误）；
- SQL 语句语法错误（如关键字拼写错误、表名/字段名错误）；
- 数据库权限不足（如无查询/修改权限）。
解决方案
- 后端检查数据库连接：
- 确认数据库服务已启动，IP/端口/密码配置正确；
- 测试数据库连接（如使用 Navicat 连接数据库，验证配置）；
- 后端检查 SQL 语句：
- 打印执行的 SQL 语句（如
console.log('SQL:', sql)），验证语法是否正确； - 确认表名、字段名与数据库一致（避免大小写敏感问题）；
- 打印执行的 SQL 语句（如
后端添加数据库异常捕获：
// Node.js 数据库异常捕获
app.get('/api/user/:id', (req, res) => {
try {
const userId = req.params.id
const user = db.query('SELECT * FROM user WHERE id = ?', userId)
if (!user) {
return res.status(404).json({ msg: '用户不存在' })
}
res.json({ code: 200, data: user })
} catch (err) {
console.error('数据库异常：', err)
res.status(500).json({ msg: '数据库查询失败，请联系管理员' })
}
})
4.3 场景 3.3：后端依赖服务故障
错误表现
后端接口依赖其他服务（如缓存服务 Redis、第三方接口、消息队列），若依赖服务未启动或故障，导致后端执行请求时报错，返回 500。
核心原因
依赖服务未启动、网络不通、接口返回异常，导致后端代码调用依赖服务时抛出异常。
解决方案
- 后端检查依赖服务状态：
- 确认依赖服务（如 Redis、RabbitMQ）已启动；
- 测试依赖服务的连接（如使用 Redis 客户端连接验证）；
后端添加依赖服务异常捕获：
// Node.js 依赖服务异常捕获
app.get('/api/user/cache/:id', async (req, res) => {
try {
const userId = req.params.id
// 调用 Redis 缓存服务
const userCache = await redis.get(`user:${userId}`)
if (!userCache) {
// 缓存未命中，查询数据库
const user = await db.query('SELECT * FROM user WHERE id = ?', userId)
await redis.set(`user:${userId}`, JSON.stringify(user), 'EX', 3600)
return res.json({ code: 200, data: user })
}
res.json({ code: 200, data: JSON.parse(userCache) })
} catch (err) {
console.error('Redis 服务异常：', err)
res.status(500).json({ msg: '缓存服务故障，请稍后重试' })
}
})
4.4 场景 3.4：服务器资源耗尽/配置错误
错误表现
线上服务器因 CPU、内存、磁盘空间耗尽，或配置参数错误（如 JVM 内存不足），导致后端服务崩溃，返回 500。
核心原因
- 服务器 CPU/内存使用率过高（如程序内存泄漏、并发量过大）；
- 磁盘空间不足（如日志文件过大占满磁盘）；
- 服务配置错误（如 JVM 堆内存设置过小，导致 OOM）。
解决方案
- 服务器资源排查：
- Linux 服务器：执行
top（查看 CPU/内存）、df -h（查看磁盘空间）、free -m（查看内存使用）； - Windows 服务器：打开任务管理器，查看 CPU/内存/磁盘使用率；
- Linux 服务器：执行
- 优化服务器配置：
- 增加服务器资源（如升级 CPU/内存）；
- 优化服务配置（如调整 JVM 堆内存
-Xms512m -Xmx1024m）； - 清理磁盘空间（如删除旧日志文件）；
- 排查程序内存泄漏：若内存使用率持续升高，可能是程序内存泄漏（如未释放对象引用），需通过工具（如 JProfiler）排查。
4.5 场景 3.5：后端服务未启动/崩溃
错误表现
后端服务未启动，或启动后因异常崩溃，导致服务器无法处理请求，返回 500（部分服务器会返回 503）。
核心原因
- 后端服务未启动（如部署后未执行启动命令）；
- 服务启动后因代码错误、资源耗尽等原因崩溃。
解决方案
- 后端启动服务：执行启动命令（如
java -jar xxx.jar、node app.js）； - 检查服务启动日志：查看服务启动日志，确认是否有启动失败信息（如端口占用、依赖缺失）；
- 配置服务自动重启：线上环境配置服务自动重启（如使用 PM2 管理 Node.js 服务、Systemd 管理 Java 服务），避免服务崩溃后无法自动恢复。
五、通用排查流程：三步定位前后端接口异常
无论遇到 404、405、500 哪种状态码，按以下「三步排查法」执行，可快速定位问题，无需盲目修改代码：
步骤 1：前端自查——确认请求配置正确
- 核对请求地址（URL）、端口、大小写，确保与接口文档一致；
- 核对请求方法（GET/POST/PUT/DELETE），确保与后端接口一致；
- 查看 Network 面板的 Request URL 和 Request Method，确认请求配置无错误；
- 本地开发时，检查代理配置（target、pathRewrite）是否正确，重启前端项目验证。
步骤 2：验证接口——用 Postman/curl 直接请求后端
绕过前端项目，用 Postman 或 curl 直接请求后端接口（真实地址），验证接口是否正常：
- 若直接请求仍返回相同状态码（404/405/500）：问题在后端，进入步骤 3；
- 若直接请求正常：问题在前端（如代理配置、地址错误），返回步骤 1 重新排查。
步骤 3：后端排查——根据状态码定位问题
- 404：检查后端路由配置（路径、前缀、方法），确认接口已部署；
- 405：检查后端 CORS 配置（是否允许 OPTIONS 方法）、接口支持的请求方法；
- 500：查看后端错误日志（异常堆栈），检查代码逻辑、数据库、依赖服务状态。
六、开发中高频避坑点（总结版）
避坑 1:404——路径拼接错误/大小写敏感
- 问题：前端多写斜杠（/api//user）、后端路由前缀不一致（前端/api/user，后端/user）；
- 解决方案：统一路径规范（如所有路径小写、无多余斜杠），前端配置 baseURL，后端统一路由前缀。
避坑 2:405——跨域预检 OPTIONS 未处理
- 问题：跨域场景下，后端未允许 OPTIONS 方法，导致预检请求 405；
- 解决方案：后端 CORS 配置必须包含 OPTIONS 方法，预检请求直接返回 200。
避坑 3:500——后端未做异常捕获
- 问题：后端代码无空值判断、数组越界等，导致未捕获异常；
- 解决方案：后端添加全局异常处理，所有接口做参数校验和空值判断，记录详细错误日志。
避坑 4：线上环境——Nginx 配置错误
- 问题：Nginx 反向代理路径不匹配、禁止请求方法，导致 404/405；
- 解决方案：核对 Nginx 的 location 路径和 proxy_pass 配置，允许必要的请求方法。
避坑 5：数据库——表名/字段名大小写敏感
- 问题：Linux 服务器下，数据库表名/字段名大小写敏感，导致 SQL 查询失败（500）；
- 解决方案：数据库表名/字段名统一小写，SQL 语句中使用小写。
七、总结：三类状态码的核心解决思路
前端请求后端返回 404、405、500 状态码的排查，核心是「先明确状态码本质，再分责任方排查」，以下是核心解决思路总结：
404 Not Found：聚焦「路径匹配」
- 核心思路：前端核对地址拼写/代理配置，后端核对路由配置/接口部署；
- 快速解决：用 Postman 直接请求后端真实地址，若仍 404 则后端路由问题，否则前端地址/代理问题。
405 Method Not Allowed：聚焦「方法与跨域」
- 核心思路：前端核对请求方法，后端核对接口方法配置和 CORS 跨域支持；
- 快速解决：跨域场景下，优先检查后端是否允许 OPTIONS 方法，非跨域场景下，核对前后端请求方法是否一致。
500 Internal Server Error：聚焦「后端代码与环境」
- 核心思路：后端查看错误日志，排查代码逻辑、数据库、依赖服务、服务器资源；
- 快速解决：后端添加全局异常捕获，定位异常堆栈，修复代码错误或环境问题。
遵循本文的排查流程和解决方案，能快速定位并解决 99% 以上的 404/405/500 状态码问题，同时养成「前端自查→接口验证→后端排查」的高效排查思维，减少前后端协作成本。
