max_execution_time不能仅靠改php.ini一劳永逸：phpEnv多版本共存，Web与CLI读取不同php.ini，需分别确认路径、重启对应服务（Apache/php-fpm），且外部调用、数据库、cURL等均需单独设超时。
max_execution_time 在 phpEnv 中不能靠改 php.ini 就一劳永逸 —— 因为 phpEnv 是多版本共存环境，每个 PHP 版本有独立的配置路径，且 Web 和 CLI 模式读取的配置文件可能不同。
确认当前生效的 php.ini 路径
在 phpEnv 控制面板里点开对应 PHP 版本的「配置文件」，或直接运行：
php --ini注意看 Loaded Configuration File 行。CLI 模式下这个路径才真正起作用；Web 请求（如 Apache/Nginx）走的是另一个
php.ini（通常是 phpenv/php/{version}/etc/php.ini 或 conf.d/ 下的覆盖文件）。
修改 php.ini 后必须重启对应服务
phpEnv 本身不管理 Web 服务器进程，只管理 PHP 二进制和配置。改完 php.ini 后：
- 如果是 Apache SAPI：需重启 Apache（不是 phpEnv）
- 如果是 Nginx + PHP-FPM：需重启
php-fpm进程（phpEnv 提供了phpenv fpm restart命令） - CLI 下改完即可立即生效，无需重启
max_execution_time = 300 写得再对也无效。
set_time_limit() 在 phpEnv 中的行为差异
该函数在 phpEnv 的 CLI 和 Web 模式下表现一致，但要注意：
- 它重置的是「剩余时间」，不是总耗时。比如已运行 28 秒后调用
set_time_limit(30)，最多还能跑 30 秒，不是总共 30 秒 - 值设为
0表示取消限制，但前提是 php.ini 中没用disable_functions = set_time_limit屏蔽它 - 某些 phpEnv 预编译包会默认禁用该函数（尤其面向共享主机场景），可运行
var_dump(ini_get('disable_functions'));确认
立即学习“PHP免费学习笔记（深入）”；
外部调用（如 shell_exec、cURL）不受 max_execution_time 控制
这是最容易翻车的地方：
-
shell_exec('sleep 60')会卡满 60 秒，哪怕max_execution_time=10 - cURL 必须单独设
CURLOPT_TIMEOUT，否则可能挂住 - 数据库查询超时要靠 PDO 的
PDO::ATTR_TIMEOUT或 MySQLi 的mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5)
max_execution_time。
复杂点在于：phpEnv 的「PHP 版本切换」不会自动同步 php.ini 修改，每次切版本都要重新检查并应用配置；更隐蔽的是，某些扩展（如 opcache）启用后可能缓存旧的 ini 设置，需要清空 opcache 或重启 FPM。
