set_time_limit() 仅限制用户态CPU时间，不控制I/O等待、数据库查询等阻塞操作；Web超时需Web服务器、PHP配置、扩展层三重控制，CLI下需pcntl_alarm或手动计时。
PHP脚本超时卡死，set_time_limit() 为什么没用？
根本原因：它只对脚本的**用户态 CPU 时间**生效，不包括 I/O 等待、数据库查询、sleep()、文件读写阻塞等耗时。比如一个 mysqli_query() 卡在慢 SQL 上 30 秒，set_time_limit(5) 完全拦不住。
常见错误现象：Fatal error: Maximum execution time of 30 seconds exceeded 依然出现，或明明调了 set_time_limit(10)，脚本却跑了 60 秒才挂。
-
set_time_limit()必须在脚本运行中调用（不能在已超时后补救），且需safe_mode关闭（PHP 5.4+ 已移除，但旧环境要注意） - CLI 模式下默认为 0（不限时），Web SAPI（如 Apache mod_php）才受
max_execution_timeini 设置约束 - 若用
php-fpm，还要检查request_terminate_timeout和request_slowlog_timeout—— 这俩是 fpm 层硬杀，比 PHP 内部超时更“暴力”
Web 环境下真正可靠的超时控制在哪配？
不是靠 PHP 函数，而是三层叠加：Web 服务器 → PHP SAPI → 应用逻辑。漏掉任何一层都可能失效。
- Apache：
Timeout指令（单位秒），影响整个请求生命周期，包括网络传输；若用mod_proxy转发，还得看后端ProxyTimeout - Nginx：
fastcgi_read_timeout（对应 PHP-FPM 响应时间）、proxy_read_timeout（反代场景），默认常为 60 秒，远高于 PHP 的max_execution_time - PHP 配置：
max_execution_time是 Web SAPI 下的兜底值，但会被set_time_limit()动态覆盖；CLI 下该值无效
典型陷阱：Nginx fastcgi_read_timeout 300，PHP max_execution_time 30，结果脚本因某次 cURL 请求卡住 200 秒——PHP 层早该死了，但 Nginx 还在等，用户看到的是 200 秒白屏后 504。
立即学习“PHP免费学习笔记（深入）”；
cURL、PDO、Redis 等扩展自带超时，别全指望 set_time_limit()
外部依赖才是超时主力战场。它们的超时机制独立于 PHP 执行时间限制，必须显式设置。
- cURL：
curl_setopt($ch, CURLOPT_TIMEOUT, 5)（整个请求耗时），CURLOPT_CONNECTTIMEOUT（仅连接阶段），二者要分开设 - PDO MySQL：
options => [PDO::ATTR_TIMEOUT => 5]（仅适用于 PDO_MYSQLND，且实际效果受mysqlnd.net_cmd_buffer_size影响）；更稳的是在 DSN 加&connect_timeout=5 - Redis（phpredis）：
$redis->setOption(Redis::OPT_READ_TIMEOUT, 3)、OPT_WRITE_TIMEOUT，注意单位是秒（不是毫秒） - file_get_contents()：只能通过
stream_context_create()设timeout，无法用set_time_limit()中断 DNS 解析或 TCP 握手
CLI 脚本怎么防无限 hang？
没有 Web 服务器兜底，max_execution_time 默认无效，全靠你自己动手。
- 用
pcntl_alarm()+ 信号处理最直接：pcntl_signal(SIGALRM, function() { exit("timeout"); }); pcntl_alarm(30);，但仅限 CLI，且不能在多线程或某些 SAPI 下用 - 循环中主动检测时间：
$start = microtime(true); while ($condition && (microtime(true) - $start) ，适合可控循环，不适合阻塞调用 - 子进程隔离：用
proc_open()启动子进程，主进程用stream_select()或proc_get_status()监控，超时则proc_terminate()—— 开销大但最可靠
最容易被忽略的一点：所有超时设置都**不保证精确到毫秒级**，尤其是系统负载高时，pcntl_alarm() 可能延迟数秒触发，curl 的 TIMESTAMP 也可能漂移。真要强实时，得上 Go 或 Rust。
