phpEnv中改max_execution_time必须同步修改php.ini、控制面板配置及.user.ini三处，并重启服务，否则仅改一处无效；还需同步调整max_input_time、memory_limit等参数并验证phpinfo()中Local Value值。
phpEnv 里改 max_execution_time 必须动三处，只改一处等于没改
phpEnv 是 Windows 下常见的 PHP 集成环境（类似 phpStudy），它的配置分层和宝塔类似，但界面更隐蔽。你改了「PHP 设置」里的 max_execution_time，页面显示保存成功，结果脚本还是 30 秒就报错——大概率是漏掉了另外两处关键配置。
这三处分别是：
-
php.ini文件中的max_execution_time（全局基础值） - phpEnv 控制面板中「PHP 版本」→「设置」→「配置修改」里显示的同名字段（它会覆盖
php.ini，但只影响该 PHP 版本下的 Web 请求） - 如果启用了
.user.ini（常见于子目录单独配置），它里面的max_execution_time会最终生效，且优先级最高
改完任意一处，都必须点击控制面板右上角的「重启 Apache」或「重启 Nginx + PHP」按钮。只点「保存」不重启，配置不会加载进正在运行的 php-cgi 或 php-fpm 进程里。
set_time_limit() 在 phpEnv 的 Apache 模块模式下有效，但在 php-fpm 模式下基本失效
phpEnv 默认使用 Apache + mod_php，此时 set_time_limit(300) 能起作用；但如果你手动切换为 php-fpm 模式（比如为了兼容某些扩展），那这行代码就几乎没用——因为 php-fpm 层有自己的 request_terminate_timeout 硬限制，它比 PHP 脚本层的计时器更早触发。
立即学习“PHP免费学习笔记（深入）”；
验证方式很简单：在脚本开头加 var_dump(ini_get('max_execution_time'));，再执行一个 sleep(40);，看是否真卡住 40 秒还是 30 秒就中断。如果中断了，说明 php-fpm 的超时在起作用，得去改 www.conf 里的 request_terminate_timeout = 600。
别只盯着 max_execution_time，max_input_time 和 memory_limit 不同步调大，上传和 POST 一样会 504
你把 max_execution_time 改成 600，但用户上传一个 200MB 文件时依然卡在 60 秒——这是因为 max_input_time 控制的是「接收并解析全部输入数据」的时间，包括 POST 内容、文件流、multipart 解析等。它的默认值常是 -1（继承 max_execution_time），但某些 phpEnv 版本会把它锁死在 60。
同步要检查的还有：
-
memory_limit：大文件上传或 JSON 解析容易爆内存，设成512M或1024M更稳妥 -
post_max_size和upload_max_filesize：这两个必须 ≥ 你要传的文件大小 - Apache 的
Timeout指令（在httpd.conf里）：它控制整个 HTTP 请求生命周期，也得 ≥ 600
改完一定要用 phpinfo() 看「Local Value」，别信面板显示的数字
phpEnv 控制面板里显示的 max_execution_time = 600，只是它读取的配置文件值；真正生效的是运行时的 Local Value。很多用户改完发现没用，就是因为 .user.ini 权限不对（必须是 644）、或者 user_ini.filename 被禁用了（php.ini 里要确保没注释掉 user_ini.filename = ".user.ini"）。
快速验证方法：
- 建个
info.php，内容就一行：<?php phpinfo(); ?> - 浏览器打开，Ctrl+F 搜
max_execution_time - 重点看「Local Value」列的数字，它才是你脚本实际被限制的值
如果这里还是 30，说明某处覆盖失败，优先查 .user.ini 是否存在、是否可读、是否写对了格式（不能有多余空格或 BOM 头）。
