php配置修改不生效，主因是改错文件：web环境用phpinfo()查“loaded configuration file”，cli环境执行php --ini确认路径；cli与fpm配置文件分离（如/etc/php/8.1/cli/php.ini和/etc/php/8.1/fpm/php.ini），需按实际sapi分别修改并重启对应服务。
改了不生效，大概率不是配置写错了，而是你根本没改对那个被加载的 php.ini。
怎么确认PHP当前读的是哪个php.ini
别猜，直接问PHP自己。在Web环境里建个 info.php，内容只有一行：<?php phpinfo(); ?>，浏览器打开它，搜索 Loaded Configuration File —— 这一行显示的路径，才是PHP实际加载的主配置文件。
命令行下执行：php --ini，看 Loaded Configuration File 对应的路径。注意：CLI（php -v、php artisan）和 FPM（Nginx/Apache后端）用的通常是两个完全不同的 php.ini 文件，比如：
-
/etc/php/8.1/cli/php.ini← 命令行用 -
/etc/php/8.1/fpm/php.ini← 网站请求用
很多人在 CLI 的 ini 里改了 upload_max_filesize，却忘了 FPM 的 ini 还是旧值，上传就必然失败。
为什么改了 php.ini 还是看到旧值
常见干扰源有三个，按优先级从高到低排列：
-
php-fpm.conf或www.conf里的php_value[]直接覆盖：比如php_value[upload_max_filesize] = 2M，这个值会压过php.ini里的设置，且无法用ini_set()动态改 -
php.ini同目录或conf.d/下的 .conf 文件：某些发行版（如 Ubuntu 的 apt 包）把扩展配置拆成20-opcache.ini、30-mysql.ini等，它们在主 ini 之后加载，也能覆盖同名指令 - 代码里用
ini_set()或 Apache 的php_admin_value：前者只对当前脚本生效，后者在httpd.conf或虚拟主机配置里，优先级高于php.ini
查的时候重点看 phpinfo() 输出里对应配置项的 Local Value 和 Master Value —— 前者是最终生效值，后者才是 php.ini 原始值。
改完之后到底要重启谁
改了哪个 SAPI 的配置，就重启对应的服务：
- 改的是
fpm/php.ini→ 必须执行sudo systemctl restart php8.1-fpm（Debian/Ubuntu）或sudo systemctl restart php-fpm（CentOS/RHEL），nginx -s reload或apache2ctl graceful不起作用 - 改的是
cli/php.ini→ 无需重启任何服务，但要注意：Composer、Artisan、Cron 脚本等走 CLI 模式，改完立刻生效 - 用宝塔、AMH 等面板 → 面板里点“重启PHP”按钮，不要只点“重载Web服务”
特别提醒：Docker 容器里改了 php.ini，必须重建容器或至少重启 PHP-FPM 进程，挂载的配置文件不会热更新。
upload_max_filesize 不生效的典型连环坑
光调大 upload_max_filesize 是不够的，它依赖三个参数协同生效：
-
file_uploads = On（必须开启，否则整个上传功能被禁用） -
upload_max_filesize = 64M（单文件上限） -
post_max_size = 100M（整个 POST 请求体上限，必须 ≥ upload_max_filesize）
三者中任意一个卡住，都会导致上传失败，错误表现可能是空白页、500、或 $_FILES 为空。建议一起检查，一起改，一起重启 FPM。
最容易被忽略的其实是 SAPI 分离这件事——CLI、FPM、Apache module 各自加载各自的 ini，连路径都不同。确认路径、确认服务、确认覆盖链，三步缺一不可。不然改十次也是白改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
