CURLOPT_TIMEOUT必须显式设置才能控制POST总超时，仅设CURLOPT_CONNECTTIMEOUT会导致传输阶段无超时保护；file_get_contents需将timeout置于http子数组内；php.ini的max_execution_time等全局限制可能覆盖cURL设置。
curl_setopt 设置 POST 超时时间不生效？先确认是否用了 CURLOPT_TIMEOUT
PHP 的 curl_setopt 中控制超时的选项有两个关键参数：CURLOPT_TIMEOUT 和 CURLOPT_CONNECTTIMEOUT。前者是整个请求（连接 + 传输）的总时限，后者仅控制建立 TCP 连接的等待时间。很多人只设了 CURLOPT_CONNECTTIMEOUT，结果 POST 数据还没发完或响应没收全就中断了，误以为“超时没生效”。
实操建议：
- 必须显式设置
CURLOPT_TIMEOUT，比如curl_setopt($ch, CURLOPT_TIMEOUT, 30)表示最多等 30 秒 - 若服务器响应慢但连接快，
CURLOPT_CONNECTTIMEOUT可设小些（如 5），避免卡在握手阶段 - 注意：该值单位是秒，支持浮点数（如 0.5），但底层 cURL 可能截断精度
- 如果 POST 数据很大或网络差，
CURLOPT_TIMEOUT必须覆盖完整传输周期，否则会提前中止
使用 file_get_contents + stream_context_create 延长 POST 超时
不用 cURL 也能发 POST，但 file_get_contents 的超时由 stream_context_create 控制，且必须通过 http 选项块配置，不能直接传 timeout 参数。
常见错误：写成 'timeout' => 30 却放在顶层数组里，实际无效。
立即学习“PHP免费学习笔记（深入）”；
正确写法示例：
$context = stream_context_create([
'http' => [
'method' => 'POST',
'header' => "Content-Type: application/x-www-form-urlencoded\r\n",
'content' => http_build_query(['key' => 'value']),
'timeout' => 30, // ✅ 必须放在 'http' 子数组内
'ignore_errors' => true,
]
]);
$response = file_get_contents('https://api.example.com', false, $context);
注意：timeout 在这里单位是秒，且只影响本次请求；它不会改变 default_socket_timeout 的全局设置。
php.ini 级别超时限制可能覆盖脚本设置
即使你在代码里把 CURLOPT_TIMEOUT 设为 120，如果 php.ini 中 max_execution_time = 30，脚本本身会在 30 秒后被 PHP 强制终止，cURL 来不及返回。
这种情况常见于 CLI 模式下未调整配置，或 Web 服务器（如 Apache、Nginx）设置了更短的请求超时。
检查与绕过方式：
- 用
ini_get('max_execution_time')查看当前值，CLI 下默认是 0（不限制），Web 下通常是 30 或 60 - 必要时调用
set_time_limit(120)延长脚本总生命周期（注意：仅对 CLI 有效，Web 模式下受 SAPI 限制） - Nginx 需同步检查
fastcgi_read_timeout，Apache 注意Timeout指令，否则 PHP 还没超时，Web 服务器已断连
POST 大文件上传时，超时逻辑更复杂
上传大文件（如 >10MB）时，CURLOPT_TIMEOUT 很容易不够用——它从 curl_exec() 开始计时，包括 DNS 查询、TCP 握手、SSL 握手、发送请求体、等待响应头、接收响应体全过程。
尤其在弱网或高延迟环境下，光是上传数据就可能耗掉十几秒。
建议拆分控制：
- 用
CURLOPT_CONNECTTIMEOUT_MS（毫秒级）精细控制连接阶段，避免卡死 - 用
CURLOPT_LOW_SPEED_LIMIT+CURLOPT_LOW_SPEED_TIME防止“假死”：例如设为 1024 字节/30 秒，表示连续 30 秒下行速率低于 1KB/s 就中断 - 启用
CURLOPT_PROGRESSFUNCTION监控上传进度，便于定位卡在哪一环 - 不要依赖单个
CURLOPT_TIMEOUT值去覆盖所有场景，它只是兜底机制
超时不是越长越好，关键是匹配业务节奏和失败容忍度；真正难调的，往往是那个既不报错也不返回、卡在中间某步的 POST 请求。
