根本原因是PHP上传配置拦截，须通过phpinfo()确认真实php.ini路径（如C:\xampp\apache\bin\php.ini），同步修改upload_max_filesize=256M、post_max_size=256M、max_execution_time=600并完整重启Apache，超100MB文件应改用mysql命令行导入。
根本不是phpmyadmin坏了，而是php在上传阶段就把整个请求拦下了——它压根没把文件传进来。
确认你改的是真实生效的 php.ini
很多人反复修改却无效，是因为编辑了错误的文件。XAMPP 加载的通常是 C:\xampp\apache\bin\php.ini（Windows）或 /Applications/XAMPP/xamppfiles/etc/php.ini（macOS），而不是 PHP 目录下的 php.ini-development 或其他副本。
- 访问
http://localhost/dashboard/phpinfo.php，搜索Loaded Configuration File，记下路径 - 用管理员权限打开该文件（Windows 下右键 → “以管理员身份运行”编辑器）
- 检查并确保以下三行存在、未被注释（开头无分号
;）、且值合理：
upload_max_filesize = 256M post_max_size = 256M max_execution_time = 600
post_max_size 必须 ≥ upload_max_filesize，否则 POST 数据在进入 PHP 前就被 Apache/Nginx 截断；max_execution_time 过小会导致大文件解析中途超时中断。
重启 Apache ≠ 刷新页面或点“Restart All”
改完 php.ini 后，必须在 XAMPP 控制面板中对 Apache 执行「Stop」→「Start」。只刷新 phpMyAdmin 页面、只重启 MySQL、甚至只点「Restart All」都不触发 PHP 配置重载。
- 重启后务必再打开
phpinfo.php，搜索确认三项值已更新 - 若仍显示旧值，大概率是文件被系统设为“只读”（Windows 下右键文件属性 → 取消勾选“只读”）
别让 phpMyAdmin 多做一次解压
即使你导出了 .sql.gz，导入时也请传 .sql 文件，并在 phpMyAdmin 导入页**取消勾选「压缩」选项**（如 gzipped、zipped）。PHP 层解压会额外消耗内存和时间，极易触发 memory_limit 不足或超时，且这个过程不报具体错误，只静默失败。
立即学习“PHP免费学习笔记（深入）”；
- 导出时：在 phpMyAdmin 导出页取消「压缩」，选「SQL」格式直出纯文本
- 传输需要压缩？用 7-Zip 或系统自带工具本地打包成 ZIP，解压后再导入
超过 100MB 就别硬扛了，直接上命令行
phpMyAdmin 是 Web 界面工具，不是数据库导入引擎。它把整个 SQL 文件读进 PHP 内存再逐行执行，遇到大文件极易因超时、内存溢出或解析中断而报“没有收到任何数据”，且不给任何线索。
- 终端执行：
mysql -u root -p your_database_name < /path/to/your_file.sql - 或登录后：
mysql> use your_database_name;→mysql> source /path/to/your_file.sql; - 命令行能暴露真实错误位置、字符集问题、
max_allowed_packet截断等所有底层细节
真正容易被忽略的是：错误提示里那句“没有收到任何数据”，听起来像前端或界面问题，但实际根源全在 PHP 上传链路的配置是否精准命中、是否真实生效——少一个环节，就卡死在那里，连日志都不会留。
