phpinfo()显示的loaded configuration file路径才是真实生效的php.ini，改完不生效首要确认是否修改了该路径文件，再排查php-fpm pool、.user.ini覆盖及opcache缓存问题，并完整重启php-fpm。
phpinfo() 显示的 Loaded Configuration File 才是真实路径
改完 php.ini 没反应，第一件事不是重启服务，而是确认你改的根本是不是 PHP 实际加载的那个文件。命令行执行 php -i | grep "Loaded Configuration File" 和网页中访问 phpinfo() 输出的 Loaded Configuration File 值，二者可能完全不同——尤其在多版本共存环境（如 phpEnv、宝塔、Kali）里，CLI 和 FPM 加载的配置文件默认就分离。
常见错误是只改了 /usr/local/php/lib/php.ini 或 /etc/php/8.2/cli/php.ini，但 Web 请求实际走的是 /etc/php/8.2/fpm/php.ini 或 /usr/local/phpenv/versions/8.1.27/etc/php.ini。如果 phpinfo() 里 Loaded Configuration File 显示为 none，说明 PHP 没找到任何 php.ini，此时所有配置走编译默认值，必须手动复制 php.ini-production 并重命名为 php.ini 放到对应路径。
php-fpm pool 配置会强制覆盖 php.ini
php.ini 的设置很容易被更高优先级的配置覆盖，尤其是 php-fpm 的 pool 文件（如 www.conf）。只要里面写了 php_value[upload_max_filesize] 或 php_admin_value[memory_limit]，php.ini 的同名项就彻底失效。
- 检查
php-fpm.conf是否含include=指令，顺着它找到实际生效的 pool 配置文件（通常是/etc/php/8.2/fpm/pool.d/www.conf） - 搜索
php_value[xxx]、php_admin_value[xxx]、php_flag[xxx]，删掉或同步修改这些行 - 改完必须完整重启
php-fpm（不是 reload），例如phpenv fpm-restart或systemctl restart php82-fpm
.user.ini 也会静默覆盖，且重载有延迟
共享主机或部分 Nginx + PHP-FPM 环境默认启用 .user.ini，它会被自动扫描并覆盖 php.ini 设置，但默认每 30 秒才重载一次——你刚改完，phpinfo() 可能还显示旧值。
检查网站根目录是否存在 .user.ini，内容类似：
upload_max_filesize = 2M post_max_size = 8M
如果存在，要么同步修改它，要么在 php.ini 中禁用：
user_ini.filename = ""
注意：该配置只能写在主 php.ini 里，不能写在 .user.ini 自身中。
OPcache 缓存 ini 解析结果，杀进程比 reload 更可靠
即使改对了文件、也改对了位置、也重启了 php-fpm，仍可能不生效——因为 OPcache 缓存了 ini 的解析树。特别是当 opcache.revalidate_freq 设得较大（比如 60），PHP 主进程不会及时重新读取 php.ini。
opcache_reset() 只清字节码，不触发 ini 重载；ini_set() 对 upload_max_filesize 这类 PHP_INI_SYSTEM 级配置完全无效。
最直接的验证方式：ps aux | grep php-fpm，看主进程（master process）的启动时间是否更新。没更新，说明重启根本没成功。容器或宝塔环境下，别直接 kill -9 或 systemctl restart，应使用面板指定操作或 docker exec -it 容器名 /bin/sh -c "kill -USR2 1"（前提是 PHP-FPM 启用了 graceful reload）。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
