PHP HTTP 超时探测器怎么写：状态码、耗时和日志验收

平时做后台系统对接短信、支付、地图、内部网关这些服务的时候，最头疼的就是HTTP请求没有边界：外部接口一卡，PHP进程就一直挂着等返回，最后业务日志里只能看到一句干巴巴的「请求失败」，根本查不到到底是对方服务挂了、网络卡了还是返回了异常状态码。写个轻量的HTTP超时探测器就能把这类问题兜住：入口传入要探测的目标地址，PHP侧预先设好请求超时阈值，拿到返回的状态码和请求耗时，最后把全量结果写进日志再返回结构化的JSON。这个小项目完全不依赖任何框架，用原生 stream_context_create 就能写完，做完可以直接放到定时任务里、后台工具页面里，或是上线前用来批量检查依赖服务的连通性。

项目目标：做一个可验收的接口探测器

这个小工具只做一件事：访问指定 HTTP 地址，并把结果整理成稳定的 JSON。它不替代完整监控系统，但能解决开发和运维常见的几个小痛点：上线前确认依赖能不能访问，定时检查第三方接口是否变慢，排查某个接口到底是返回异常状态还是请求层面失败。

最终返回格式可以保持简单：

{
  "ok": true,
  "status": 200,
  "cost_ms": 184,
  "error": "",
  "target": "https://example.test/health"
}

如果外部地址慢、不可访问或返回非 2xx 状态，接口也要给出明确结果，而不是让调用方等到 PHP 进程自然结束。

环境准备：一个入口文件和一个日志文件夹

项目结构不需要复杂，准备一个 public/probe.php 做入口，再准备一个 storage/logs 写探测结果。日志文件夹要确保 PHP 运行用户有写入权限；如果部署在容器里，建议把日志路径挂到持久化位置，避免容器重启后现场丢失。

http-probe/
  public/
    probe.php
  storage/
    logs/
      probe.log

本地调试时可以用 PHP 内置服务启动：

php -S 127.0.0.1:8080 -t public

核心代码：设置超时并整理状态码

入口先读取 url 参数，然后交给 probe_url 函数访问。这里使用 stream_context_create 设置请求方法、请求头和超时时间；ignore_errors 设为 true 后，即使远端返回 404 或 500，PHP 也能拿到响应体和响应头，方便我们提取状态码。

 false,
        'status' => 0,
        'cost_ms' => 0,
        'error' => 'url 参数不是有效地址',
        'target' => $target,
    ], JSON_UNESCAPED_UNICODE);
    return;
}

$result = probe_url($target, $timeout);
write_probe_log(__DIR__ . '/../storage/logs/probe.log', $result);

echo json_encode($result, JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT);

function probe_url(string $url, int $timeout): array
{
    $start = microtime(true);
    $context = stream_context_create([
        'http' => [
            'method' => 'GET',
            'timeout' => $timeout,
            'ignore_errors' => true,
            'header' => "User-Agent: php-http-probe/1.0\r\nAccept: application/json,text/plain,*/*\r\n",
        ],
    ]);

    $body = @file_get_contents($url, false, $context);
    $costMs = (int) round((microtime(true) - $start) * 1000);
    $status = parse_status_code($http_response_header ?? []);
    $error = '';

    if ($body === false) {
        $error = error_get_last()['message'] ?? '请求失败';
    } elseif ($status = 300) {
        $error = 'HTTP 状态异常';
    }

    return [
        'ok' => $error === '',
        'status' => $status,
        'cost_ms' => $costMs,
        'error' => $error,
        'target' => $url,
    ];
}

function parse_status_code(array $headers): int
{
    $firstLine = $headers[0] ?? '';
    if (preg_match('/HTTP\/\S+\s+(\d{3})/', $firstLine, $match)) {
        return (int) $match[1];
    }
    return 0;
}

function write_probe_log(string $file, array $result): void
{
    $line = json_encode([
        'time' => date('c'),
        'target' => $result['target'],
        'status' => $result['status'],
        'cost_ms' => $result['cost_ms'],
        'error' => $result['error'],
    ], JSON_UNESCAPED_UNICODE);

    file_put_contents($file, $line . PHP_EOL, FILE_APPEND | LOCK_EX);
}

这段代码刻意把状态码解析、请求探测和日志写入拆开。后面要接入定时任务、后台页面或告警通道时，不用再从一大坨入口逻辑里抠代码。

本地运行：先测成功，再测异常

服务启动后，先用一个稳定地址测试成功路径，再用不存在的路径或本地慢接口测试异常路径。不要只测一次 200 返回就结束，探测器的价值恰恰在异常场景。

curl "http://127.0.0.1:8080/probe.php?url=https%3A%2F%2Fexample.test%2Fhealth"

成功时看 ok 是否为 true，status 是否为 200，cost_ms 是否落在预期范围。异常时重点看 error 字段是否有可读信息，日志里是否同步记录了同一条结果。

集成到定时任务时要加阈值

如果这个探测器要放到定时任务里，不建议把所有非 200 都简单算成“服务挂了”。更实用的做法是把状态码、耗时和错误信息拆开判断：状态码连续异常再告警，耗时超过阈值先记录为慢调用，完全不可访问才提高告警级别。

验收：看返回、日志和慢接口表现

验收这个小项目，至少要跑三组用例：正常接口、返回 404 或 500 的接口、响应明显变慢的接口。只要这三类都能稳定返回 JSON，日志也能留住目标地址、状态码、耗时和错误信息，就说明工具已经能支撑基本排查。

验收清单：
1. 无效 url 参数返回 400
2. 正常接口返回 ok=true
3. 非 2xx 状态能写入 error
4. 慢接口能体现 cost_ms
5. storage/logs/probe.log 有结构化记录

如果部署到生产环境，建议再加一层白名单，只允许探测固定域名或内部服务，避免这个入口被滥用成随意访问外部地址的工具。

相关问题

为什么不用空超时配置？

空超时会把等待边界交给默认配置，线上很容易拖住 PHP 工作进程。探测器本来就是为了识别慢依赖，超时时间必须显式写出来。

ignore_errors 会不会吞掉错误？

它不会让错误消失，而是让非 2xx 响应也能被读取。真正的错误判断仍然要看状态码和返回结果，不能只看读取函数有没有拿到内容。

日志里要不要保存响应体？

默认不建议保存完整响应体，里面可能有隐私字段或过大的文本。通常记录目标地址、状态码、耗时和错误摘要就够排查用。

这个探测器能直接当监控系统吗？

不建议。它适合做轻量检查和排查辅助；如果要长期监控，还需要配合任务调度、告警渠道、指标面板和权限控制。