改错文件、不重启服务、只调函数，三者任一出错均导致 max_execution_time 失效；须确认 apache 加载的真实 php.ini 路径，修改后必须重启 apache 服务，且需同步调整 timeout、request_terminate_timeout 及 upload/post 限制。
改错文件、不重启服务、只调函数，这三件事里任意做错一个，max_execution_time 就不会生效。
确认 Apache 实际加载的 php.ini 路径
phpEnv 里常有多个 php.ini 文件共存，但 Apache 只认它自己加载的那个。你改了 C:\phpEnv\php\php.ini，而 Apache 加载的是 C:\phpEnv\apache\bin\php.ini，那修改就完全无效。
- 新建一个
info.php，内容为<?php phpinfo(); ?>，用浏览器访问 - 在页面中搜索
Loaded Configuration File，看它显示的具体路径 - 如果值是
none，说明 Apache 没加载任何php.ini，此时脚本会退回到默认 30 秒，且ini_set('max_execution_time', ...)也无效（因该指令是PHP_INI_SYSTEM级别）
修改 php.ini 并重启 Apache 服务
找到上一步确认的真实路径后，直接编辑该 php.ini 文件：
- 搜索
max_execution_time，去掉行首分号（取消注释），改为需要的值，例如：max_execution_time = 300 - 顺手检查并同步调整其他关联参数：
max_input_time = 300、memory_limit = 512M（避免内存先爆） - 保存后，**必须在 phpEnv 控制面板中重启 Apache 服务**——只刷新网页或重启 MySQL 没用
为什么 set_time_limit(0) 在 phpEnv 里经常失效
set_time_limit(0) 只重置 PHP 层计时器，绕不过 Apache 自身的 Timeout 指令（默认 300 秒）。一旦超时，Apache 会直接断连，返回空白页或 500 错误，PHP 甚至收不到中断信号。
- 查
C:\phpEnv\apache\conf\httpd.conf，找Timeout行，确保它 ≥ 你设的max_execution_time - 如果你启用了 php-fpm（比如切换过运行模式），还要同步检查
php-fpm.conf中的request_terminate_timeout，它优先级更高，且无法被set_time_limit()绕过 - 某些扩展（如 Xdebug）或输出缓冲开启时，
set_time_limit()的行为可能异常，不建议依赖它做主控
大 SQL 导入等场景要额外注意 upload 和 post 限制
导入大文件失败，往往不是执行时间不够，而是上传阶段就被拦下了。
- 在同一个
php.ini文件中，确认以下三项都已修改并大于目标文件体积：upload_max_filesize = 2048M、post_max_size = 2048M（必须 ≥ 前者）、max_execution_time = 3600 - 改完仍失败？优先放弃 phpMyAdmin，改用命令行：
mysql -u root -p database_name - 若必须用 phpMyAdmin，且文件极大，
bigdump.php分块导入比调参数更可靠
最易被忽略的一点：phpEnv 的 Apache 默认不启用 .htaccess 的 php_value，所以别指望靠它临时改 max_execution_time——除非你手动在 httpd.conf 里开了 AllowOverride FileInfo 并确认对应目录有读取权限。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
