必须同步修改post_max_size、upload_max_filesize和memory_limit三个参数，且post_max_size≥upload_max_filesize、memory_limit＞post_max_size；修改后需重启Apache/Nginx服务，并确认phpinfo()中“Loaded Configuration File”路径下的php.ini已生效，同时检查并清理网站根目录下可能覆盖配置的.user.ini文件。
phpEnv 下改 post_max_size 不能只改一个值，必须同步调 upload_max_filesize、memory_limit，且改完不重启服务等于白改。
确认你正在编辑的 php.ini 是生效的那个
phpEnv 是 Windows 下的 PHP 环境管理工具，它会为每个 PHP 版本维护独立的配置文件，但 Web 请求（如 Apache 或 Nginx）用的不一定是你看到的那个。常见误区是改了 CLI 模式下的 php.ini（比如 C:\phpenv\versions\8.2\php.ini），结果网站仍报 413 或空 $_POST —— 因为 Apache/Nginx 实际加载的是另一个路径下的配置。
验证方式：在网站根目录放一个 info.php，内容为 <?php phpinfo(); ?>，访问后搜索 “Loaded Configuration File”，看显示的路径才是真实生效的 php.ini。这个路径通常在 C:\phpenv\versions\{version}\Apache24\conf\php.ini 或类似位置，取决于你选的 Web 服务器集成方式。
必须同时修改的三个参数及其关系
post_max_size 不是孤立存在的，它和另外两个参数形成硬性依赖链，任意一环断裂都会导致表单提交失败（比如 $_POST 为空、$_FILES 丢失、返回 400 错误）：
立即学习“PHP免费学习笔记（深入）”；
-
post_max_size必须 ≥upload_max_filesize：否则哪怕单个文件没超，整个 POST 包含文件+字段的总大小一超就直接被 PHP 丢弃，连解析都不做 -
memory_limit必须 >post_max_size：PHP 在解析 POST 数据时会先载入内存，若内存不够，脚本会在$_POST还没生成前就因 OOM 终止 - 单位统一用
M（大写），别写m、MB或漏单位，PHP 会静默忽略无效值
例如你要支持 100MB 的表单提交（含大附件）：
post_max_size = 128M upload_max_filesize = 100M memory_limit = 256M
改完不重启 Apache/Nginx 就不生效
phpEnv 界面里点“重启 PHP”只是重启 PHP-FPM 进程，如果你用的是 Apache 模块模式（默认），必须手动重启 Apache 才能重载 php.ini。Nginx 用户则需同时重启 nginx 和对应版本的 php-fpm。
操作路径（以 phpEnv 自带的 Apache 为例）：
- 打开 phpEnv 主界面 → 右上角「服务」→ 「Apache」→ 「重启」
- 或者进命令行：
net stop apache2.4 && net start apache2.4（路径名以实际服务名为准） - 重启后务必再访问
info.php，确认页面上显示的post_max_size值已更新，别信面板里的“保存成功”提示
注意 phpEnv 的 .user.ini 覆盖行为
部分 phpEnv 集成包会在网站根目录自动生成 .user.ini，它的优先级高于 php.ini，且对 post_max_size 这类 PHP_INI_PERDIR 类型的指令有效。如果你改完 php.ini 并重启了，但 phpinfo() 显示的仍是旧值，大概率是 .user.ini 在作祟。
检查并处理方法：
- 进你的网站根目录（如
C:\phpenv\www\myapp\），看是否存在.user.ini - 若有，用记事本打开，搜索
post_max_size或upload_max_filesize - 删掉对应行，或改成和
php.ini一致的值，保存即可（无需重启，phpEnv 默认每 5 分钟自动重载）
最麻烦的情况是：你改了 php.ini，也删了 .user.ini 里的冲突项，但上传还是失败——这时候要查 Web 服务器层限制，比如 Apache 的 LimitRequestBody 或 Nginx 的 client_max_body_size，它们在 phpEnv 的 Apache/Nginx 配置文件里，比 PHP 层更早拦截请求。
