API调用返回错误？别慌，这些常见问题你可能每天都遇到

做开发的时候，API调用返回错误太常见了。早上刚泡好咖啡，正准备联调接口，结果浏览器控制台跳出一串红字：401 Unauthorized。这时候别急着翻文档，先看看是不是你自己漏了点什么。

最常见的：请求头没带对

尤其是Authorization字段。比如你用的是JWT，但忘了在header里加上Bearer前缀，服务器当然不认你。代码看起来是这样：

fetch('/api/user', {
  headers: {
    'Authorization': 'eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...' // 少了 Bearer
  }
})

正确写法应该是：

fetch('/api/user', {
  headers: {
    'Authorization': 'Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...'
  }
})

参数传错了位置

有些API要求参数放在query string里，你却塞进了body；或者该用POST的地方用了GET。比如想查用户ID为123的信息，接口明确要GET /users?id=123，结果你写成POST /users/123，还附了个空body，那返回404也不奇怪。

跨域问题，本地调试的痛

你在localhost跑前端，后端在另一个端口，一发请求就报CORS error。浏览器拦得死死的，根本到不了服务器。这时候不是API有问题，是预检请求OPTIONS被拒绝了。解决办法要么后端加Access-Control-Allow-Origin，要么本地配个代理转发。

网络层也得看一眼

有时候错误码是200，但返回内容却是HTML——登录页。说明你被重定向了。可能是登录态失效，API网关把你踢到了登录地址。这种情况在内网系统特别多，明明接口文档写得好好的，一调就跳sso页面，查nginx日志才发现302了。

别忽略返回体里的提示

很多API虽然返回500，但response body里其实写了具体原因。比如{"error": "missing required field: email"}，比状态码有用多了。Chrome开发者工具的Network标签页点进去，看Preview或Response那一栏，经常能一眼看出问题。

模拟请求试试看

不确定是不是自己代码的问题，可以用curl或者Postman直接发请求。比如：

curl -H "Authorization: Bearer xxx" \n     "https://api.example.com/v1/profile"

如果这都能拿到数据，那问题肯定出在你的代码逻辑里，别再盯着后端骂了。

频率限制也容易中招

有些API每分钟最多调20次，超了就返回429 Too Many Requests。你本地测试手快，连点几下，结果被限流了。等半分钟再试又好了，搞得像玄学。这时候看响应头里的Retry-After字段，就知道得歇多久。

环境搞混了最坑人

开发环境、测试环境、生产环境的API地址不一样。你改了一半配置，一半请求发到测试服，一半发到线上，结果数据对不上，还以为是接口bug。建议在请求时顺手打个log，把最终URL和参数都输出来，排查起来省一半时间。