核心是主动控制超时：不设curlopt_timeout（默认0，永不超时）和curlopt_connecttimeout（默认0），dns解析、tcp连接或服务无响应时php进程会无限等待，直至max_execution_time触发致命错误；必须同时设置二者（如3秒和8秒）并配合curlopt_returntransfer等关键选项。
PHP调用外部API不超时，核心不是“避免超时”，而是“主动控制超时”——不设 CURLOPT_TIMEOUT 或 CURLOPT_CONNECTTIMEOUT，请求就可能卡死进程，尤其在DNS失败、服务无响应或网络抖动时。
为什么没设超时就容易卡住
cURL 默认 CURLOPT_TIMEOUT 是 0（永不超时），CURLOPT_CONNECTTIMEOUT 也默认为 0。这意味着：DNS 解析卡住、TCP 连接挂起、后端迟迟不发响应头，你的 PHP 脚本会一直等下去，直到 PHP 的 max_execution_time 触发 fatal error（通常是 30 秒或 60 秒），而不是 cURL 自己返回错误。
常见现象包括：页面白屏、AJAX 请求 pending 状态持续几十秒、CLI 脚本 hang 住不动。
- 仅设
CURLOPT_TIMEOUT不够 —— 它只限制整个请求耗时，不防 DNS 卡顿 - 必须同时设
CURLOPT_CONNECTTIMEOUT（建议 ≤ 3 秒）和CURLOPT_TIMEOUT（建议 ≤ 10 秒，视业务容忍度） - HTTPS 场景下若跳过证书验证（
CURLOPT_SSL_VERIFYPEER => false），仍需设超时 —— SSL 握手失败也可能阻塞
POST JSON 请求时超时配置易漏的点
发送 JSON 数据时，除了超时，还常因其他选项缺失导致看似“卡住”，实则是请求根本没发出去或被服务端静默拒绝。
- 必须显式设置
CURLOPT_RETURNTRANSFER => true，否则curl_exec()返回true或false，拿不到响应体 -
CURLOPT_POSTFIELDS直接传数组会触发application/x-www-form-urlencoded编码，要发 JSON 必须先json_encode()并配Content-Type: application/json - 别漏掉
CURLOPT_HTTPHEADER，否则服务端可能因缺少Content-Type拒绝解析或返回 415 错误 - 示例关键片段：
$ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'https://api.example.com/v1/submit'); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode(['id' => 123])); curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 3); curl_setopt($ch, CURLOPT_TIMEOUT, 8); $response = curl_exec($ch);
file_get_contents 怎么加超时也不卡
file_get_contents() 本身不支持细粒度超时控制，但通过 stream_context_create() 可以精确设定连接与读取超时，且无需额外扩展。
-
timeout参数控制整个请求生命周期（含 DNS、连接、读取），不能区分连接和读取阶段 - 若需更精细控制（比如 DNS 失败快速失败），还是推荐 cURL
- 正确写法示例（GET 请求）：
$context = stream_context_create([
'http' => [
'method' => 'GET',
'header' => "Authorization: Bearer abc123\r\n",
'timeout' => 10,
'ignore_errors' => true
]
]);
$response = file_get_contents('https://api.example.com/data', false, $context);
注意：ignore_errors => true 才能让它返回响应体（含 4xx/5xx 状态码内容），否则遇到非 2xx 就直接返回 false，掩盖真实问题。
超时后怎么判断是真失败还是可重试
超时本身不等于业务失败；有些场景（如支付回调、短信下发）需要区分“网络层失败”和“业务层拒绝”。
- 用
curl_errno($ch)判断：值为28表示超时（CURLE_OPERATION_TIMEDOUT），7是无法连接（CURLE_COULDNT_CONNECT），这两类通常可重试 - 但若
curl_exec()成功返回，却拿到 HTTP 状态码 503 或 429，说明服务端已响应 —— 这不属于超时，而是业务限流或临时不可用，重试策略应不同 - 不要只靠
$response === false做判断：cURL 超时返回false，但服务端返回空 JSON 或 204 也会让json_decode($response, true)得到null，需结合curl_getinfo($ch, CURLINFO_HTTP_CODE)和json_last_error()综合判断
真正难的不是设两个数字，而是理解每个超时参数作用在哪一环节（DNS → TCP connect → TLS handshake → send request → wait response headers → read body），以及服务端返回的 HTTP 状态码和响应体内容是否可信。线上环境建议把 CURLOPT_VERBOSE 关掉，但用 curl_getinfo() 记录实际耗时和状态码，方便后续分析是哪一环拖慢了请求。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
