超时不是 phpMyAdmin 的 bug，而是 PHP 上传限制、phpMyAdmin 自身 $cfg['ExecTimeLimit']、MySQL max_allowed_packet 三重限制叠加所致；需同步调整 php.ini、config.inc.php 和 MySQL 配置，并更新 wp_options 表中 siteurl 和 home 字段。
直接结论：超时不是 phpmyadmin 的 bug，而是 php 上传限制、phpmyadmin 自身 $cfg['exectimelimit']、mysql max_allowed_packet 三重卡点叠加——改错任意一层，导入都会失败。
为什么改了 max_execution_time 还报 “Script timeout passed”
因为 phpMyAdmin 不依赖 PHP 的 max_execution_time，它用自己轮询计时的 $cfg['ExecTimeLimit']（默认 300 秒）。哪怕你把 php.ini 设成 3600，它照样在第 301 秒弹窗中断。
- 必须改的是
phpmyadmin/config.inc.php（不是config.default.php），加在$cfg['blowfish_secret']后面一行：$cfg['ExecTimeLimit'] = 0; - 改完不用重启 Apache，但必须清空浏览器缓存或换无痕窗口重进 phpMyAdmin 才生效
- 宝塔/XAMPP/WAMP 用户注意：确认
config.inc.php路径是否正确（如宝塔是/www/server/phpmyadmin/下的文件）
upload_max_filesize 和 post_max_size 哪个才真拦路？
真正生效的是两者中更小的那个值。比如你设了 upload_max_filesize = 2048M，但 post_max_size = 8M，那上传阶段就直接被 Web 服务器截断——phpMyAdmin 根本收不到完整数据，页面可能空白或跳 413 错误。
- 至少同步设为：
upload_max_filesize = 2048M、post_max_size = 2048M、memory_limit = 1024M - 改完必须重启 Web 服务（Apache/Nginx/PHP-FPM），否则无效
- 用
phpinfo()页面查 “Loaded Configuration File”，确认你改的是 Web SAPI 实际加载的那个php.ini
MySQL 报错 “MySQL server has gone away” 或导入中途白屏？
这大概率是 max_allowed_packet 太小。WordPress 导出的 SQL 常含百万级 INSERT，单条语句长度轻松破 10MB；MySQL 默认仅允许 4MB 单包，超限就静默丢弃，表现就是卡住、白屏、或无提示中断。
- 查当前值：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_allowed_packet';" - 临时提升（本次会话有效）：
SET GLOBAL max_allowed_packet = 268435456;（256MB） - 永久生效：编辑 MySQL 配置文件（Windows 是
my.ini，Linux/macOS 是my.cnf），在[mysqld]下加：max_allowed_packet = 256M，然后重启 MySQL 服务
导入成功后 WordPress 打不开？别漏了 wp_options 里的两个字段
即使 SQL 导入成功，站点仍可能 404 或样式错乱——因为导出的数据库里 wp_options 表中的 siteurl 和 home 还是旧域名。
立即学习“PHP免费学习笔记（深入）”；
- 进 phpMyAdmin → 选中目标数据库 → 点
wp_options表 → 找到option_name为siteurl和home的两行 → 手动改成新地址（如http://localhost或你的正式域名） - 如果用了子目录或 HTTPS，务必同步检查并替换所有相关 URL 字段，否则后台登录、静态资源、链接都会失效
真正麻烦的不是改配置，而是三处配置要同时生效且路径准确——php.ini 改错位置、config.inc.php 没清缓存、MySQL 配置没重启服务，任一环节掉链子，就会卡在看似莫名其妙的环节。动手前先跑一遍 phpinfo() 和 SHOW VARIABLES，比盲目改完再试更省时间。
