改了php.ini不生效，首要确认是否修改了web环境实际加载的文件（用phpinfo()查“loaded configuration file”），再检查fpm pool、.user.ini等高优先级覆盖项，最后清除opcache并用宝塔指定方式重启php-fpm。
改了 php.ini 却没生效，大概率不是你手抖写错了，而是根本没改对文件、没触达真正加载的配置层，或者进程压根没换新上下文。
怎么确认你改的是 PHP Web 环境实际加载的 php.ini
命令行执行 php -i | grep "Loaded Configuration File" 显示的是 CLI 模式路径，和 Web 环境完全无关。必须用 phpinfo() 页面查——在网站根目录建一个 info.php，内容为 <?php phpinfo(); ?>，浏览器访问后搜索 “Loaded Configuration File”，那个路径才是 Nginx + PHP-FPM 实际读的 php.ini。常见错误是改了 /etc/php/8.2/cli/php.ini，但 Web 用的是 /etc/php/8.2/fpm/php.ini。
为什么改了 php.ini 还被覆盖？看 php_admin_value 和 user.ini
PHP-FPM 的 pool 配置（如 /etc/php/8.2/fpm/pool.d/www.conf）里允许用 php_admin_value[upload_max_filesize] 强制覆盖 php.ini；Apache 下的 .htaccess 里用 php_value 也能覆盖；共享主机还可能通过 .user.ini 生效——它会被自动扫描，但默认每 30 秒才重载一次。检查这些位置是否存在同名配置项，优先级：pool 配置 > .user.ini > php.ini。
重启 PHP-FPM 不等于配置已落地，还要防 OPcache 缓存旧解析树
宝塔或手动重启时，如果只执行 systemctl restart php82-fpm，而 OPcache 的 opcache.validate_timestamps=1 且 opcache.revalidate_freq 设得较大（比如 2 秒），PHP 主进程仍可能沿用缓存的 ini 解析结果。更稳妥的做法是：
- 先调用
opcache_reset()（需 PHP 脚本可执行，或通过宝塔 OPcache 管理页） - 再用宝塔面板「软件商店 → PHP → 设置 → 服务 → 重启」，或执行
/etc/init.d/php-fpm-82 restart - 验证：用
php -r "echo ini_get('upload_max_filesize');"查 CLI 值，再用phpinfo()页面确认 Web 值
注意：opcache_reset() 只清内存字节码，不触发 ini 重载；ini_set() 也不能改 upload_max_filesize 这类 PHP_INI_SYSTEM 级配置——它们只能靠重启进程生效。
容器或宝塔环境里别直接 kill 或 systemctl 操作
宝塔管理的 PHP 进程有独立守护机制，用 pkill php-fpm 或 systemctl restart php-fpm-82 可能导致主进程未更新、子进程残留、面板状态错乱。Docker 容器里改了 php.ini 必须重建镜像或至少 docker exec -it 容器名 /bin/sh -c "kill -USR2 1"（前提是 PHP-FPM 配置了 graceful reload）。最省事的验证方式：改完后立刻 ps aux | grep php-fpm，看主进程启动时间是否更新——没更新，说明重启根本没成功。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
