PHP脚本执行时间修改本质是调整对应PHP版本的php.ini中max_execution_time值，或用set_time_limit()函数临时覆盖，同时需同步检查Web服务器（如Nginx fastcgi_read_timeout、Apache Timeout）超时配置。
phpEnv 下修改 PHP 脚本执行时间，本质是改它所管理的 PHP 版本的 php.ini 文件，而不是 phpEnv 自身有独立配置项。 它不提供图形界面或命令行开关来直接调大超时，所有生效方式都落在底层 PHP 的配置机制上。
确认你正在用的 PHP 版本及其 php.ini 路径
phpEnv 可能同时管理多个 PHP 版本（如 7.4、8.1、8.3），每个版本都有自己的 php.ini。改错文件等于白改。
- 运行
php --ini，看输出里的 “Loaded Configuration File” 路径 —— 这才是当前 CLI 模式生效的配置文件 - 如果是 Web 环境（如 Apache/Nginx + php-fpm），需访问一个含
phpinfo()的页面，查 “Loaded Configuration File” 对应的路径 - 常见位置示例：
C:\phpEnv\php\php-8.2.12\php.ini（Windows）或/usr/local/phpenv/versions/8.2.12/etc/php.ini（Linux/macOS）
直接编辑对应 php.ini 中的 max_execution_time
这是最稳定、全局生效的方式，适用于你控制服务器且能重启服务的场景。
- 打开上面确认的
php.ini文件，搜索max_execution_time - 把原值（默认通常是
30）改成你需要的秒数，例如：max_execution_time = 600 - 如果真要取消限制（谨慎！），设为
max_execution_time = 0 - 保存后，必须重启对应的服务：Apache/Nginx + php-fpm（不是只重启 phpEnv）
- 注意：部分 phpEnv 封装的 Nginx + php-fpm 组合，可能需要分别执行
phpenv restart nginx和phpenv restart php-fpm（若有该命令）；否则手动 systemctl 或 kill -USR2
脚本内用 set_time_limit() 临时覆盖（推荐用于单次长任务）
适合不想动全局配置、或仅某个导出/同步脚本需要延长时间的情况。它在运行时生效，且优先级高于 php.ini 值（只要没被禁用）。
立即学习“PHP免费学习笔记（深入）”；
- 在 PHP 脚本最开头插入：
set_time_limit(0);（无限）或set_time_limit(900);（15 分钟） - 该函数重置的是“从调用点开始的剩余时间”，不是总耗时；多次调用会刷新计时器
- 常见失效原因：
set_time_limit被disable_functions禁用（检查php.ini中该项是否含它）；或运行在 CGI/FastCGI 模式下（phpEnv 默认多为 php-fpm，通常支持） - CLI 模式下它默认有效；Web 模式下还受 Web 服务器自身超时影响（如 Nginx 的
fastcgi_read_timeout）
别漏掉 Web 服务器层的超时设置
即使 PHP 允许跑 1 小时，Nginx/Apache 也可能在 60 秒就断开连接，返回 504 Gateway Timeout —— 这和 Maximum execution time exceeded 是两回事，但用户感知一样。
- Nginx 用户：检查
fastcgi_read_timeout（php-fpm 场景）或proxy_read_timeout（反代场景），单位秒，建议 ≥ PHP 的max_execution_time - Apache 用户：确认
Timeout指令（默认 300 秒），以及ProxyTimeout（若用 mod_proxy） - 这些配置不在 phpEnv 管理范围内，需手动改 Nginx/Apache 配置并 reload
真正麻烦的从来不是改哪一行配置，而是改完之后忘了 Web 服务器还有自己的一套超时逻辑，或者误以为 set_time_limit(0) 能绕过所有限制 —— 它绕不过 max_input_time、绕不过 fastcgi_read_timeout、也绕不过 Linux 的 kill -9（比如 OOM killer）。动手前先 php --ini 和 phpinfo() 对齐真实环境，比反复试错快得多。
