修改php.ini并重启Apache才能使max_execution_time生效，路径为XAMPP安装目录下的php.ini，需同步调整max_input_time、post_max_size等参数，并建议大库导出优先使用mysqldump命令行。
直接改 php.ini 并重启 Apache 才真正生效
在 XAMPP 中，max_execution_time 只有在 Apache 启动时从 php.ini 读取一次。改完不重启，phpinfo() 显示的仍是旧值，脚本照样超时。
正确路径是：C:\xampp\php\php.ini（Windows）或 /Applications/XAMPP/xamppfiles/etc/php.ini（macOS）。别去控制面板点“Config → PHP Settings”，那只是跳转入口，最终还得编辑这个文件。
用管理员权限打开（否则保存失败），搜索 max_execution_time = 30，改成你需要的值，例如：
-
max_execution_time = 300（5 分钟，适合导出中等数据库） -
max_execution_time = 600（10 分钟，适合 WordPress 更新或 Drupal 安装） - 不建议设为
0：XAMPP 默认以 Apache 模块方式运行 PHP，设0可能导致脚本卡死、无法被正常终止，且部分环境会 fallback 到 Apache 自身的Timeout（默认 300 秒）
改完后，在 XAMPP 控制面板中必须先点 Stop Apache，再点 Start Apache——单击 Restart 有时不重载配置。
立即学习“PHP免费学习笔记（深入）”；
ini_set() 和 set_time_limit() 在 XAMPP 里只能临时打补丁
这两个函数能在脚本里用，但限制极多，不是正解：
-
ini_set('max_execution_time', '600')必须放在脚本最开头，且只对当前请求有效；如果php_admin_flag[disable_functions]禁用了它（XAMPP 默认没禁），就直接失效 -
set_time_limit(600)从调用位置起重新计时，但多次调用可能被 Apache 的Timeout指令覆盖——而 XAMPP 的 Apache 配置不暴露该参数修改入口 - 它们都绕不开底层 Web SAPI 机制，一旦触发 Apache 层超时，PHP 层设置毫无意义
只建议用于调试单个脚本，比如快速验证某段逻辑是否真卡在执行时间上。上线或批量操作前，务必回到 php.ini 改全局配置。
别漏掉 max_input_time 和 post_max_size
很多“超时”根本不是脚本执行慢，而是卡在请求接收阶段：
-
max_input_time控制 PHP 解析 POST/GET/上传数据的最长时间，默认为-1（继承max_execution_time），但如果你手动改过它，就必须同步更新，否则大 POST 提交（如 phpMyAdmin 导出勾选几十张表）可能在 30 秒就断连 -
post_max_size和upload_max_filesize也得一起调大：phpMyAdmin 导出页面提交的是一个巨量选项的 POST 请求，不是上传文件，但它的请求体常超默认8M；建议都设为64M，且确保post_max_size >= upload_max_filesize
这些参数都在同一个 php.ini 文件里，改完同样要重启 Apache。
phpMyAdmin 导出卡住？优先用 mysqldump 命令行
Web 界面本质是封装，所有限制（内存、执行时间、POST 大小）都会叠加。几百 MB 级别数据库，mysqldump 几乎不会中断：
- Windows：打开终端，
cd C:\xampp\mysql\bin，执行mysqldump -u root -p --databases your_db > backup.sql - macOS：终端进
/Applications/XAMPP/xamppfiles/bin，同样执行mysqldump命令 - 加
--single-transaction可避免 InnoDB 锁表；加| gzip > backup.sql.gz能流式压缩，不占额外内存
这才是真正脱离 PHP 层限制的可靠方案。界面导出只适合小库或快速验证，别把它当主力工具。
