ThinkPHP中需通过cURL选项显式设置毫秒级超时：CURLOPT_CONNECTTIMEOUT_MS（300–500ms）控制建连，CURLOPT_TIMEOUT_MS（800–1500ms）控制总耗时；think\Http的timeout参数在cURL驱动下无效，必须用options透传；超时返回false而非异常，须判空降级，不可依赖try-catch。
ThinkPHP 中如何用 curl_setopt 控制单次接口调用超时
ThinkPHP 本身不内置「下游接口超时隔离」机制，所有 HTTP 调用最终都落到 PHP 的 curl 或 file_get_contents 层。关键不是框架封装了什么，而是你是否显式设置了超时参数。
常见错误是只设 timeout（总耗时），却忽略 connecttimeout（建连阶段），导致下游 DNS 慢或服务不可达时，整个请求卡满 30 秒甚至更久。
-
CURLOPT_CONNECTTIMEOUT_MS：建议设为 300–500ms，控制 TCP 连接建立上限 -
CURLOPT_TIMEOUT_MS：建议设为 800–1500ms，覆盖完整请求+响应读取 - 避免使用
CURLOPT_TIMEOUT（秒级）——精度太粗，容易误伤 - 若用
think\facade\Http，需传入options数组，直接透传 cURL 参数，不能只靠timeout键
示例：
$response = Http::post('https://api.example.com/data', $data, [
'timeout' => 1.2, // ❌ 无效！这是 think\Http 的伪 timeout，不控制底层 cURL
'options' => [
CURLOPT_CONNECTTIMEOUT_MS => 400,
CURLOPT_TIMEOUT_MS => 1200,
CURLOPT_RETURNTRANSFER => true,
]
]);
为什么 think\Http 的 timeout 参数经常失效
因为 think\Http 的 timeout 是个「兼容性补丁」，只在部分驱动下生效（如内置的 StreamRequest），而一旦项目启用了 cURL 驱动（默认行为），它就完全被忽略——框架没把 timeout 映射到 CURLOPT_TIMEOUT_MS。
- 查当前驱动：
Http::getDriver()，返回curl就说明走的是 cURL 底层 - 只要驱动是
curl，就必须通过options显式传CURLOPT_TIMEOUT_MS - 别信文档里“支持 timeout 配置”这种笼统描述，要看源码
think\http\Client中buildCurlOptions()方法是否处理了该字段
下游超时后如何不让主流程崩掉
超时本身不会抛异常，但 cURL 在超时后会返回 false，且 curl_error() 为 "Operation timed out after XXX milliseconds"。如果代码里没检查返回值或没 try/catch，后续直接调用 $res->json() 就会报错。
立即学习“PHP免费学习笔记（深入）”；
- 必须判断返回值是否为
false，而不是依赖异常捕获 - 推荐统一包装一层安全调用函数：
function safeHttpCall($url, $data = [], $opts = []) { $res = Http::post($url, $data, ['options' => array_merge([ CURLOPT_CONNECTTIMEOUT_MS => 400, CURLOPT_TIMEOUT_MS => 1200, ], $opts)]); return $res === false ? null : $res; } - 业务层拿到
null后，走降级逻辑（缓存、默认值、空数据），而非继续执行 - 不要在控制器里写
try { $x = Http::get(...) } catch (\Exception $e) { ... }——cURL 超时不抛异常
并发调用多个下游时，如何防止互相拖慢
ThinkPHP 默认是串行调用，但如果用了 Http::multi() 或自己用 curl_multi，就得注意：所有请求共享同一个超时窗口。一个慢接口卡住，其余即使已返回，也得等最慢的那个结束。
-
Http::multi()不支持 per-request 超时，所有请求共用最后一个timeout值，慎用 - 真要并发且隔离，得手写
curl_multi_init()+ 单独为每个 handle 设CURLOPT_TIMEOUT_MS - 更稳妥的做法是改用消息队列异步拉取下游数据，主流程只查本地缓存或兜底结果
- 监控重点不是「平均耗时」，而是
99% 分位超时率和connecttimeout 触发次数，这两项更能暴露 DNS 或网络抖动问题
真正难的不是设几个毫秒数，而是让所有调用点都走同一套超时配置+降级路径。漏掉一个 file_get_contents 直接调用，整条链路就失去保护。
