必须同步修改php.ini的max_execution_time、apache的timeout、fastcgi的fcgidiotimeout（若启用），并重启phpenv服务；仅改php.ini无效，否则仍会504。
phpEnv 是 Windows 下的 PHP 集成环境（类似 XAMPP、WampServer），它自带 Apache 和 PHP，但配置路径和生效逻辑与标准部署略有不同。改 max_execution_time 不能只盯 php.ini —— phpEnv 会优先读取其自定义的配置文件，且 Apache 和 PHP-FPM 模式下行为也不同。
确认你用的是 Apache 还是 PHP-FPM 模式
phpEnv 默认使用 Apache + mod_php，但部分版本支持切换为 Nginx + PHP-FPM。这直接影响配置修改位置：
- Apache 模式：改
php.ini或站点根目录下的.user.ini（phpEnv 通常启用 user_ini.filename） - PHP-FPM 模式：必须改对应 pool 的配置（如
www.conf中的request_terminate_timeout），同时仍需同步php.ini的max_execution_time - 不确定？访问
http://localhost/phpinfo.php，搜索Server API：显示Apache 2.0 Handler就是 Apache；显示FPM/FastCGI就是 PHP-FPM
改 phpEnv 的 php.ini（最常用且推荐）
phpEnv 的 php.ini 不在系统默认路径，而是在其安装目录下的 PHP 子目录中，例如：C:\phpEnv\php\php-8.2.12\php.ini。直接改这里最稳妥：
- 先停掉 phpEnv 的 Apache 或 PHP-FPM 服务（用面板或托盘图标）
- 打开对应 PHP 版本的
php.ini，搜索max_execution_time - 把值改成你需要的秒数，比如：
max_execution_time = 300 - 保存后重启 phpEnv 的 Web 服务（不是仅刷新页面）
- 验证是否生效：写个
test.php，内容为<?php echo ini_get('max_execution_time'); ?>，访问看输出是否为 300
为什么 set_time_limit() 有时不生效
在 phpEnv 的 Apache 模式下，set_time_limit() 大多数时候可用，但要注意几个硬限制：
- 如果 php.ini 中设置了
disable_functions = set_time_limit，函数调用会静默失败（检查phpinfo()的disable_functions行） -
set_time_limit(0)在 Apache 下可能被忽略——某些 SAPI 实现不支持取消限制 - 它只重置“脚本 CPU 执行时间”，对 cURL 等 I/O 阻塞无效；若卡在
curl_exec()上，得单独设CURLOPT_TIMEOUT - 调用位置很重要：必须在超时发生前执行，且不能放在条件分支里漏掉
别忘了 Apache 和 PHP-FPM 自身的超时联动
phpEnv 若用 Apache，光改 max_execution_time 不够，还必须匹配 Apache 的 Timeout 和 FastCGI 的 fastcgi_read_timeout（如果启用了 mod_fcgid）。否则会出现 504 Gateway Timeout 或请求被 Apache 主动切断：
- Apache 主配置（
httpd.conf）中找Timeout，建议设为 ≥max_execution_time+ 10，例如：Timeout 310 - FastCGI 配置（
httpd-fcgid.conf或虚拟主机段）中加：FcgidIOTimeout 310 - PHP-FPM 模式下，除了
php.ini，还要改www.conf中的：request_terminate_timeout = 300 - 改完这些，必须重启整个 phpEnv 服务链（Apache/Nginx + PHP-FPM），不能只 reload
真正卡住的往往不是 max_execution_time 本身，而是没设 timeout 的 cURL、没索引的 MySQL 查询、或循环里反复 fopen() 却没 fclose()。这个参数只是最后一道闸门，不是性能问题的解药。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
