唯一可靠方式是修改php 7.4 fpm实际加载的php.ini（如/etc/php/7.4/fpm/php.ini），并执行sudo systemctl restart php7.4-fpm彻底重启服务；cli或apache配置文件无效，面板操作、.htaccess及ini_set()在fpm环境下基本被忽略。
直接改 /etc/php/7.4/fpm/php.ini（或 /etc/php/7.4/apache2/php.ini）并重启对应服务，才是唯一可靠方式；面板点点、.htaccess、ini_set() 在 PHP 7.4 + FPM 环境下基本无效或被忽略。
确认你改的是 PHP 7.4 FPM 实际加载的 php.ini
PHP-FPM 不读 CLI 或 Apache 的配置文件。运行以下命令查清真实路径：
php-fpm7.4 -i | grep "Loaded Configuration File"
输出类似 /etc/php/7.4/fpm/php.ini —— 这才是你要编辑的文件。别去动 /etc/php/7.4/cli/php.ini，它只影响命令行脚本。
- 如果用 Nginx + PHP-FPM，必须改
fpm目录下的php.ini - 如果用 Apache + mod_php（少见），才改
apache2目录下的版本 -
php --ini显示的是 CLI 配置，和 Web 请求无关
upload_max_filesize 和 post_max_size 必须配对改，且单位写法严格
只调 upload_max_filesize 没用，post_max_size 卡在前面就会静默失败（表单提交直接 500 或卡住）。
- 设
upload_max_filesize = 128M，则post_max_size = 150M（留余量） - 单位只能是
K、M、G（大写），写成128MB或128m会被 PHP 当作 0 处理 - 顺手检查
memory_limit是否 ≥post_max_size（例如设为256M） - 确保
file_uploads = On（默认是 On，但某些精简镜像会关掉）
改完必须重启 php7.4-fpm，光 reload 不行
PHP-FPM 进程不响应 SIGHUP，systemctl reload php7.4-fpm 或宝塔「重载配置」不会重新读取 php.ini。
- 正确操作：
sudo systemctl restart php7.4-fpm - Nginx 用户还需执行：
sudo systemctl reload nginx（同步检查client_max_body_size） - Apache 用户执行：
sudo systemctl restart apache2 - 验证是否生效：
php-fpm7.4 -i | grep -E 'upload_max_filesize|post_max_size'
上传仍失败？先看错误类型再排查层级
不同报错指向不同环节，别一上来就重改配置：
- 报
413 Request Entity Too Large→ Nginx 层拦截，查client_max_body_size - 报
The uploaded file exceeds the upload_max_filesize directive→ PHP 层生效，但值太小或改错文件 - 页面空白 / 500 / 卡 loading →
post_max_size 或 <code>max_execution_time太短（建议设为300） - 报
move_uploaded_file(): Unable to move→upload_tmp_dir权限不对或不在open_basedir白名单内
PHP 7.4 的限制逻辑没变，但 FPM 架构让配置加载更“刚性”——改哪、重启谁、看哪个输出，三者必须严丝合缝，漏一环就白忙。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
