phpEnv中Maximum execution time exceeded需同步修改php.ini、Apache Timeout及PHP-FPM配置，因ini_set()在mod_php下无效，且存在Web服务器、SAPI、浏览器三层超时限制。
phpEnv 提示 Maximum execution time exceeded，不是改个 max_execution_time 就能解决的——它背后至少有三层超时在同时起作用：PHP 自身计时器、Web 服务器代理层、以及底层 SAPI 行为限制。
为什么 ini_set('max_execution_time', 0) 在 phpEnv 里常失效
phpEnv 默认使用 Apache + mod_php 模式，而 max_execution_time 在该 SAPI 下属于 PHP_INI_SYSTEM 级别指令，ini_set() 调用直接被忽略，不报错也不生效。
- 检查方式：
var_dump(ini_get('max_execution_time'));看输出是否真变了 - 若仍为 30 或旧值，说明
ini_set没起作用，必须换配置层级 - phpEnv 的 Apache 配置通常走
.htaccess，但需确认AllowOverride Options已启用，否则php_value max_execution_time 0会被静默跳过 - 更稳妥的做法是直接编辑 phpEnv 内置的
php.ini（路径类似C:\phpEnv\php\php.ini），改完重启 Apache 服务
Apache + phpEnv 下必须同步调的三个地方
只改 PHP 层，请求早被 Apache 或 fastcgi 拦截了。常见组合是 Apache → mod_php，但部分 phpEnv 版本也支持切换到 PHP-FPM，得先确认当前模式：
- 查
phpinfo()页面里的Server API：显示Apache 2.0 Handler就是 mod_php；显示FPM/FastCGI则走 PHP-FPM - mod_php 场景：除
php.ini外，还需在 Apache 的httpd.conf或虚拟主机配置里加Timeout 300（单位秒） - PHP-FPM 场景（较少见但存在）：必须进
php-fpm.conf或对应 pool 文件，写php_admin_value[max_execution_time] = 0；php_value在这里无效 - 所有修改后必须执行
net stop apache2.4 && net start apache2.4（Windows）或对应重启命令，热加载不生效
set_time_limit(0) 的真实行为边界
它只是关掉 PHP 内部的软计时器，不代表脚本能无限跑下去。实际仍受制于：
立即学习“PHP免费学习笔记（深入）”；
- Apache 的
Timeout指令（默认 300 秒），超时后直接 kill 进程 - 浏览器自身连接超时（Chrome 通常 5~6 分钟无响应就断开）
- Windows 系统对 CGI 进程的默认存活限制（尤其 phpEnv 这类集成环境）
- 如果脚本含
sleep()、file_get_contents()、cURL等阻塞调用，它们各自还有独立超时，默认可能几秒就崩，和max_execution_time无关
真正要延长运行时间，优先改配置而非函数
临时加 set_time_limit(0) 或 ini_set() 容易漏掉前置耗时逻辑——比如脚本开头读大文件、连数据库慢、或 autoload 加载大量类，这些都在设置语句之前就发生了。
- 最可靠路径：打开
C:\phpEnv\php\php.ini，找到并修改三行： max_execution_time = 0-
max_input_time = 0（防 POST/GET 解析卡住） -
memory_limit = 512M（避免内存爆掉触发 OOM 而非超时） - 然后重启 Apache，再验证
phpinfo()中三项值是否更新 - 若仍失败，用
error_log("start: " . microtime(true), 3, "c:/temp/phpenv.log");手动打点，确认到底是哪段卡死
复杂点在于：phpEnv 是封装环境，它的 Apache 和 PHP 配置可能被多层覆盖（如全局 httpd.conf、vhost、.htaccess、php.ini、甚至注册表注入）。最容易被忽略的是——你以为改了 php.ini，实际 phpEnv 启动时加载的是另一个副本，或者用了缓存的配置快照。
