改$cfg['exectimelimit']=0仅绕过phpmyadmin自身计时器，php层max_execution_time、mysql层max_allowed_packet、web服务器fastcgi_read_timeout或timeout等限制仍存在；真正可靠方案是分层排查并用mysql命令行导入。
直接改 $cfg['exectimelimit'] 为 0 并不能解决所有超时问题——它只绕过 phpmyadmin 自身的计时器，而 php 层、mysql 层、web 服务器层的限制依然存在。真正稳的方案是分层排查+命令行兜底。
为什么改了 max_execution_time 还报“Script timeout passed”？
phpMyAdmin 的导入流程里有两套超时机制：PHP 的 max_execution_time 是底层执行上限，但它的前端逻辑会主动读取自身配置项 $cfg['ExecTimeLimit']（默认 300 秒），每执行一段就检查一次。即使你把 PHP 的值调到 3600，只要 $cfg['ExecTimeLimit'] 没同步改，它照样在 300 秒掐断。
- 修改位置：打开
XAMPP\phpMyAdmin\config.inc.php（不是config.default.php） - 添加或修改：
$cfg['ExecTimeLimit'] = 0;（设为 0 表示禁用） - 生效前提：清空浏览器缓存，或换无痕窗口重进 phpMyAdmin；无需重启 Apache
导入中途卡住、白屏、没报错？先查 max_allowed_packet
这不是超时，是 MySQL 拒绝接收整条语句——比如一条含 10MB JSON 字段的 INSERT，若超过服务端缓冲区上限，MySQL 直接静默丢包，phpMyAdmin 就卡在“正在导入…”不动。
- 查当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 临时提升（仅本次会话）：
SET GLOBAL max_allowed_packet = 268435456;（256MB） - 永久生效：编辑
my.ini（Windows）或my.cnf（macOS/Linux），在[mysqld]下加：max_allowed_packet = 256M - 改完必须重启 MySQL 服务，否则不生效
nginx/apache 报 504 Gateway Timeout？那是网关先扛不住
PHP 脚本可能还在跑，但 nginx 或 apache 等不到响应就主动断开连接。这个超时和 PHP 完全无关，得单独调。
- Nginx 用户：检查
location ~ \.php$块里的fastcgi_read_timeout，至少比max_execution_time大 20 秒 - Apache + mod_php：确认
Timeout指令（主配置或虚拟主机内）已调高，别留默认 60 秒 - 用了 Cloudflare？免费版硬性 100 秒超时，无法绕过，只能直连或升级
真正可靠的大文件导入方式：跳过 phpMyAdmin
命令行导入不经过 HTTP 请求、PHP 解析、进度渲染三层瓶颈，也不受 $cfg['ExecTimeLimit']、post_max_size、max_execution_time 任何一项影响。
- 确保 MySQL 正在运行（XAMPP 面板显示 Running）
- 终端进入
XAMPP\mysql\bin目录，执行：mysql -u root -p --default-character-set=utf8mb4 your_db_name - 登录后输入：
source C:/path/to/your/file.sql;（路径用正斜杠，Windows 也适用） - 如 SQL 含大量
INSERT，导入前手动加：SET FOREIGN_KEY_CHECKS=0; SET UNIQUE_CHECKS=0;，导入后再恢复
最易被忽略的一点：命令行导入失败时，错误信息往往比 phpMyAdmin 更具体——比如字符集不匹配、权限不足、SQL 语法嵌套过深（如 DELIMITER 未正确闭合），这些在 Web 界面里常被吞掉或显示为白屏。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
