PHP stream_context_create 如何限制 HTTP 请求：超时、重定向与响应体验收

PHP 代码用 file_get_contents() 访问上游时，最容易留下三个隐患：请求一直等、重定向链条失控，以及对方返回 404/500 后拿不到足够证据。把 HTTP 选项集中放进 stream_context_create()，再检查 $http_response_header，就能把这三个边界变成可测试的请求契约。

小型内部接口可以继续使用 PHP 原生流，但至少显式设置 timeout、follow_location、max_redirects 和 ignore_errors，并从响应头确认实际状态；不要只用返回值是否为 false 判断成功。

为什么只写 file_get_contents 不够

最短的写法看起来很干净：

$body = file_get_contents('https://api.example.test/profile');
if ($body === false) {
    throw new RuntimeException('request failed');
}

它没有表达等待多久、是否接受跳转、失败状态是否需要保留响应体，也没有告诉后续代码该核对哪个 HTTP 状态。生产排查时，单独一条 request failed 很难区分连接超时、证书问题、404 还是远端返回了格式错误的 JSON。

把 HTTP 请求参数写成明确契约

下面这段代码只做一件事：访问一个 JSON 接口，并把请求参数、HTTP 状态和 JSON 解析分开。stream_context_create() 的参数必须按“包装器名 => 选项”嵌套，HTTP 选项放在 http 下。

 [
        'method' => 'GET',
        'header' => "Accept: application/json\r\n",
        'timeout' => 3.5,
        'follow_location' => 0,
        'max_redirects' => 0,
        'ignore_errors' => true,
    ],
]);

$body = file_get_contents($url, false, $context);
$statusLine = $http_response_header[0] ?? '';

if (!preg_match('/^HTTP\/\S+\s+(\d{3})\b/', $statusLine, $match)) {
    throw new RuntimeException('missing HTTP status');
}

$status = (int) $match[1];
if ($status = 300 || $body === false) {
    throw new RuntimeException("upstream status={$status}");
}

$data = json_decode($body, true, 512, JSON_THROW_ON_ERROR);
if (!isset($data['id'])) {
    throw new RuntimeException('response field id is missing');
}

echo "profile_id={$data['id']}\n";

这里把 ignore_errors 设为 true，是为了让 404 或 500 时仍有机会读取错误体和响应头；真正的成功判断仍由状态码和业务字段共同完成。follow_location=0 后，服务端返回 301/302 时请求停在当前响应，不会悄悄跳到另一个地址。

timeout、重定向和失败响应分别管什么

timeout 是读取超时，单位是秒，可以写成 3.5。未设置时，PHP 会使用 default_socket_timeout。这个值不等于业务总耗时预算：DNS、建连、读取和应用重试仍要放进整体预算里。

follow_location 控制是否跟随 Location，max_redirects 控制最多跟几次；文档中的默认上限是 20。对外部地址或不完全受信任的跳转，建议显式关闭跟随，再把 3xx 记录下来交给调用方决策。

ignore_errors 只影响失败状态码下的内容读取。它不会修改 HTTP 状态，也不会抑制 PHP 的其他流错误，所以日志要同时保留状态行、响应体截断摘要和异常上下文。

和 curl 方案怎么取舍

如果项目只需要一次简单 GET、少量请求头和明确的状态码判断，原生流少一个依赖，配置也足够直观。需要连接复用、代理认证、复杂上传、细粒度 TLS、重试策略或统一中间件时，应该使用项目已有的 HTTP 客户端；不要把 stream_context_create() 扩展成半套客户端。

无论选哪种实现，验收顺序都应保持一致：先看传输是否完成，再看 HTTP 状态，再看内容类型和 JSON 结构，最后才把字段交给业务逻辑。

容易踩到的边界

• 只判断 $body !== false：ignore_errors=true 下，404 响应也可能有可读取的正文。
• 把 max_redirects 写成很大：跳转目标和链路数量都应纳入安全边界，尤其是用户可控 URL。
• 把 3.5 当成整个请求最多 3.5 秒：它主要约束流读取，业务重试和后续解析仍会继续耗时。
• 直接信任 JSON：先检查 Content-Type 和 HTTP 状态，再用 JSON_THROW_ON_ERROR 解析。

常见问题

如何让 PHP 不跟随 301 和 302？

在 http 选项中设置 follow_location => 0，同时把 max_redirects => 0 写清楚，并从响应头记录 3xx 状态。

ignore_errors 会不会把 500 当成成功？

不会。它只是允许读取失败状态码对应的响应内容，状态码仍需通过 $http_response_header 单独判断。

timeout 应该写多少？

先按上游的正常响应基线和业务总预算设置，再用浮点秒数表达；不要直接把开发机的 default_socket_timeout 当成接口 SLA。

什么时候不适合用 stream_context_create？

当请求需要连接池、复杂认证、统一重试、代理/TLS 管理或多种 HTTP 方法封装时，优先使用项目已有的成熟客户端。

把一次请求变成可验收的结果

stream_context_create() 适合做小而清楚的 HTTP 调用：参数集中、跳转可控、失败正文可留证。真正上线前，把状态行、超时、响应类型和业务字段都写进检查逻辑，后续看到“上游失败”时才有足够证据判断是网络、跳转、HTTP 状态还是内容本身出了问题。