CLI下max_execution_time默认为0且忽略php.ini，须用set_time_limit()或-d参数；Web下受Nginx、PHP-FPM、PHP三层超时叠加限制，最小值优先生效。
max_execution_time 在 CLI 和 Web 下完全不互通
改 php.ini 里的 max_execution_time 对命令行脚本（php script.php）根本没用——CLI 模式下该值默认是 0（不限时），且完全忽略 php.ini 配置。你看到脚本卡死，却去改 php.ini，属于方向性错误。
- Web 场景（Apache/Nginx + PHP-FPM）：生效，但受多层限制（如 Nginx 的
fastcgi_read_timeout、PHP-FPM 的request_terminate_timeout） - CLI 场景：必须用
set_time_limit(120)或启动时加-d max_execution_time=120 -
set_time_limit(0)在 CLI 下才真正无限；Web 下设为 0 可能被 Nginx/FPM 先截断
set_time_limit() 不会中断阻塞式系统调用
它只计 PHP 用户态执行时间，一旦进入 fsockopen()、stream_socket_client()、sleep()、数据库长查询等系统调用，计时器就暂停。你设了 30 秒，但远端服务无响应，脚本照样挂住不动。
- HTTP 请求超时要靠
curl_setopt($ch, CURLOPT_TIMEOUT_MS, 5000)或 Guzzle 的timeout选项 - MySQL 连接/查询超时需设置
mysqli.options或 PDO 的PDO::ATTR_TIMEOUT -
set_time_limit()调用后会重置计时器，比如运行 25 秒后调用set_time_limit(20)，总限时变成 45 秒
Web 环境下真正起作用的是三层超时叠加
仅改 max_execution_time 很可能白忙——Nginx 和 PHP-FPM 各自还有独立超时配置，且优先级更高。
- Nginx 层：
fastcgi_read_timeout 60（从 FPM 返回首字节开始计时） - PHP-FPM 层：
request_terminate_timeout = 60s（覆盖max_execution_time，且不触发 PHP 错误，直接 kill 进程） - PHP 层：
max_execution_time = 30（仅限脚本逻辑执行，不包含 I/O 等待） - 三者中最小的那个最先生效，建议保持 Nginx ≥ FPM ≥ PHP，避免出现 504 或静默终止
上传大文件时别只改 max_execution_time
上传超时不是单靠 max_execution_time 控制的，max_input_time 才管“接收 POST 数据”的耗时，尤其在慢网或大文件场景下更关键。
立即学习“PHP免费学习笔记（深入）”；
-
max_input_time = 600（单位秒），设为 -1 表示继承max_execution_time，设为 0 才真正不限 - 还需同步调整
post_max_size、upload_max_filesize、memory_limit - 如果用了 Nginx，记得加
client_max_body_size 32m，否则请求根本到不了 PHP
request_terminate_timeout 和 Nginx 的 fastcgi_read_timeout，它们不报 PHP 错误，只丢 502/504，排查起来特别隐蔽。 
