PHP获取HTTP状态码及接口返回判断方法

在PHP中准确获取HTTP接口的真实状态码，唯一可靠的方法是使用cURL配合`curl_getinfo($ch, CURLINFO_HTTP_CODE)`——必须在`curl_exec()`执行后、`curl_close()`前调用，且确保`CURLOPT_NOBODY`为false；任何依赖`http_response_code()`或手动解析响应头的方式都不可靠，而`get_headers()`仅适用于简单GET调试，无法满足生产环境对请求方法、认证头、超时控制和重定向逻辑的严苛要求；特别要注意：状态码为0并非业务错误，而是网络层失败（如DNS解析失败、SSL验证不通过或超时），需结合`curl_errno()`和`curl_error()`精准定位问题，同时根据业务场景审慎处理重定向行为，避免因自动跳转导致方法变更或状态误判。

用 curl_getinfo() 拿状态码最可靠

直接读响应头或靠 http_response_code() 都不准——前者可能没收到完整头，后者只返回 PHP 自己设的（比如你用 header("HTTP/1.1 404 Not Found") 才生效），跟实际 HTTP 请求无关。

真正要测接口返回状态，必须走 cURL 并在请求结束后调用 curl_getinfo($ch, CURLINFO_HTTP_CODE)：

$ch = curl_init("https://api.example.com/data");
curl_setopt($ch, CURLOPT_NOBODY, false);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HEADER, false);
curl_exec($ch);
$status = curl_getinfo($ch, CURLINFO_HTTP_CODE); // ✅ 这才是真实状态码
curl_close($ch);

• CURLOPT_NOBODY 设为 false（默认值），否则拿不到响应体，某些服务还会因此返回 204 或拒绝响应
• 别依赖 CURLOPT_HEADER 开关来“解析状态行”，cURL 内部已解析好，curl_getinfo 直接取最稳
• 如果 curl_exec() 返回 false，说明连接失败（如 DNS 错、超时），此时 curl_getinfo(..., CURLINFO_HTTP_CODE) 会是 0，需单独判断

遇到 0 状态码，先查 curl_error() 和 curl_errno()

状态码为 0 不代表接口返回了 0，而是 cURL 根本没发出去请求。常见原因有网络不通、域名无法解析、SSL 验证失败、超时等。

必须配合错误检查才能定位问题：

$ch = curl_init("https://api.example.com/data");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);

if ($response === false) {
    $errno = curl_errno($ch);
    $error = curl_error($ch);
    // 例如：$errno === 7 → "Failed to connect to ..."
    // $errno === 60 → "SSL certificate problem"
}
curl_close($ch);

• curl_errno() 比错误字符串更利于自动化判断，比如 7 是连接拒绝，28 是超时，60 是证书验证失败
• 若用自签名证书测试，加 curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false) 可绕过验证，但仅限开发环境
• 别把 0 当成业务异常（如 404/500），它属于基础设施层失败，处理逻辑应和 HTTP 状态码分离

get_headers() 能用，但不推荐用于生产接口检测

它确实能快速拿到状态行，比如 get_headers("https://api.example.com/data")[0] 可能返回 "HTTP/1.1 200 OK"，但隐患明显：

• 不支持 POST/PUT 等方法，只能发 GET
• 无法传 Authorization、Content-Type 等关键头，很多 API 拒绝无头请求
• 默认不跟随重定向，get_headers($url, 1) 虽可开启，但返回结构混乱，状态码可能来自中间跳转而非最终响应
• 超时控制弱，默认 60 秒且无法细粒度设置连接/读取超时

除非只是临时调试一个公开 GET 接口，否则别把它当主力方案。

注意重定向对状态码的影响

cURL 默认会跟随 301/302，最终 curl_getinfo(..., CURLINFO_HTTP_CODE) 返回的是**最后一次响应的状态码**，不是初始请求的。这通常符合预期，但有些场景需要原始响应码。

• 禁用自动跳转：curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false)，此时 302 就真返回 302
• 想同时看跳转链路？启用 CURLOPT_HEADER + CURLOPT_NOBODY，再手动解析 Location 头，但复杂度陡增
• 部分 API 用 307/308 做临时重定向且要求保持方法（如 POST），此时 CURLOPT_FOLLOWLOCATION 会把它转成 GET，导致后端报错——务必确认重定向行为是否符合协议

真实接口里，3xx 状态往往意味着鉴权失败或资源迁移，不能简单当成“成功”或“失败”处理，得结合 Location 头和业务规则判断。

到这里，我们也就讲完了《PHP获取HTTP状态码及接口返回判断方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！