php 的 `max_execution_time` 仅限制脚本实际 cpu 执行时间，不计算 `sleep()`、curl 等阻塞式 i/o 操作所耗费的挂起时间，因此 `sleep(45)` 不会触发超时终止。
在 PHP 中，max_execution_time（默认通常为 30 秒）是一个CPU 执行时间上限，而非“总耗时”或“墙钟时间（wall-clock time）”。这意味着：只有 PHP 解释器正在 actively 执行 PHP 字节码（如循环计算、函数调用、数组操作等）的时间才会计入该限制；而所有让出控制权、进入内核等待状态的操作——例如 sleep()、usleep()、file_get_contents()（含远程 HTTP）、curl_exec()、数据库查询（PDO/MySQLi）、fread() 阻塞读取、stream_socket_client() 连接等待等——均不消耗 max_execution_time。
✅ 正确理解示例：
// ✅ 此代码将被终止（约 30 秒后抛出 Fatal Error）
$start = microtime(true);
while (microtime(true) - $start < 45) {
// 空循环持续占用 CPU —— 计入 max_execution_time
}
echo "Done"; // 实际不会执行❌ 错误测试方式（误导性）：
// ❌ 此代码将完整执行 45 秒，不受 max_execution_time 限制
echo "Start: " . date('H:i:s') . "\n";
sleep(45); // 内核级休眠，PHP 不执行任何指令 → 时间不计费
echo "End: " . date('H:i:s') . "\n"; // 45 秒后才输出⚠️ 注意事项：
立即学习“PHP免费学习笔记（深入）”；
- set_time_limit(15) 或 ini_set('max_execution_time', 15) 同样只重置后续 CPU 执行时间限额，对已进入 I/O 等待的状态无影响；
- CLI 模式下 max_execution_time 默认为 0（无限制），而 Web SAPI（如 Apache/FPM）才启用该限制；
- 若需真正限制总耗时（含等待），应结合 pcntl_alarm()（CLI）、信号处理，或在应用层使用超时逻辑（如 cURL 的 CURLOPT_TIMEOUT_MS、PDO 的 PDO::ATTR_TIMEOUT），或借助 microtime() 手动校验累计耗时；
- 对于长任务（如批量文件生成），推荐改用异步队列（如 Redis + Worker）或分片处理（yield/Generator + 分页），避免依赖 max_execution_time 做流程控制。
? 总结：max_execution_time 是一个CPU 时间熔断机制，不是“任务总时长看门狗”。调试时切勿用 sleep() 验证其有效性；真实业务中，应针对 I/O 操作单独设置超时，并用主动计时+中断逻辑保障整体响应性。
