phpMyAdmin不控制WordPress上传限制，失败根源在PHP配置；必须修改php.ini中upload_max_filesize、post_max_size、max_execution_time等参数并重启服务，且需验证WordPress媒体库实际上传效果。
phpMyAdmin 本身不控制 WordPress 的文件上传限制，它只是个数据库管理工具；你看到的“上传失败”或“最大限制 XX KB”，其实是 PHP 运行环境的配置在起作用，而 phpMyAdmin 的导入页面恰好暴露了这些限制。想靠改 phpMyAdmin 配置来放大 WordPress 媒体库上传能力，是方向错了。
为什么改 phpMyAdmin 的 $cfg['ExecTimeLimit'] 没用
phpMyAdmin 的 $cfg['ExecTimeLimit'] 只影响 SQL 导入脚本的执行时长，和 WordPress 后台上传媒体文件完全无关。WordPress 上传走的是自己的 PHP 处理流程（wp-admin/async-upload.php 等），不经过 phpMyAdmin 的任何逻辑。即使你把 $cfg['ExecTimeLimit'] 设为 0，WordPress 媒体库仍会卡在 upload_max_filesize 或 Nginx 的 client_max_body_size 上。
phpMyAdmin 页面显示的“最大限制”其实是 PHP 配置的镜像
当你在 phpMyAdmin 导入页看到类似 “(最大限制: 8,192 KB)” 的提示，它直接读取的是当前 PHP 实例的 upload_max_filesize 和 post_max_size 两个 ini 值，并取其中较小者。这个值也同步决定 WordPress 媒体库能显示的上限——因为它们共享同一套 PHP 配置。
-
upload_max_filesize = 64M：单个上传文件最大体积 -
post_max_size = 64M：整个 POST 请求体最大体积（必须 ≥upload_max_filesize） - 若两者不一致，比如设成
upload_max_filesize=128M但post_max_size=32M，实际生效的就是 32M
真正要改的三个地方，缺一不可
WordPress 上传大文件失败，往往不是单一环节的问题。常见组合限制如下：
- PHP 层：
upload_max_filesize、post_max_size、max_execution_time、max_input_time—— 必须在php.ini（或.user.ini）里改，且需重启 PHP-FPM 或 Apache/Nginx - Web 服务器层：Nginx 需加
client_max_body_size 512m;到 server 或 location 块；Apache 若用mod_php可通过.htaccess改，但多数托管环境禁用 - WordPress 层：
@ini_set()在functions.php中仅对部分 CGI 模式有效，且无法突破 PHP 主配置硬限，纯属补丁，不建议依赖
验证时别只看 phpMyAdmin 页面
修改完配置后，别只刷新 phpMyAdmin 导入页确认“最大限制”变大了就以为万事大吉。WordPress 媒体库是否真能传，得实测：
- 进 WordPress 后台 → 媒体 → 添加新文件，观察按钮下方显示的“最大上传文件大小”是否更新
- 用一个略大于原限制（如原 2M，现试 5M）的 JPG 文件上传，看是否报
upload_max_filesize错误还是卡在 502/504 或超时 - 如果上传中途断开或白屏，大概率是
max_execution_time或 Web 服务器超时（如 Nginx 的fastcgi_read_timeout）没调够
最容易被忽略的是：改了 php.ini 却忘了重启 PHP 服务，或改了错误版本的 PHP 配置（比如服务器装了 PHP 7.4 和 8.2，但你改的是 7.4 的 ini，而 WordPress 实际跑在 8.2 上）。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
