php配置不生效需确认修改的是web实际加载的php.ini（用phpinfo()查“loaded configuration file”路径），检查是否被pool.conf或.user.ini覆盖，重启php-fpm并验证主进程时间更新，开发时调低opcache.validate_timestamps。
PHP 8.5.5 配置改了不生效，不是版本新导致的“bug”，而是你没触达真正起作用的配置层——文件改错、进程没重载、或者被更高优先级配置覆盖了。
确认改的是 Web 环境实际加载的 php.ini
CLI 和 Web 用的 php.ini 完全不同。执行 php --ini 看的是命令行路径，对 Web 无效。
- 在网站根目录建个
info.php，内容为<?php phpinfo(); ?>，浏览器访问后搜 “Loaded Configuration File”，那个路径才是 Nginx + PHP-FPM 实际读的文件 - 常见错误：改了
/etc/php/8.5/cli/php.ini，但 Web 走的是/etc/php/8.5/fpm/php.ini - PHP 8.5.5 没改变这个机制，只是修复了底层解析逻辑，不会绕过你改错文件的问题
检查是否被 php_admin_value 或 .user.ini 覆盖
PHP-FPM 的 pool 配置（比如 /etc/php/8.5/fpm/pool.d/www.conf）里写死的 php_admin_value[upload_max_filesize]，会直接无视 php.ini 里的同名项。
- 优先级顺序是：
pool.conf>.user.ini>php.ini -
.user.ini默认每 30 秒扫描一次，改完要等或手动触发重载（部分主机不支持立即生效） - 用
phpinfo()页面查对应配置项的 “Master Value” 和 “Local Value”，如果两者不一致，说明被覆盖了
重启 PHP-FPM 后主进程时间没更新
只执行 systemctl restart php85-fpm 不等于配置已落地——可能子进程残留、主进程没换新上下文。
- 执行
ps aux | grep php-fpm，看主进程（master）的 STARTED 时间是否更新；没更新=重启失败 - 宝塔环境别用
pkill或裸systemctl，应通过面板操作或使用宝塔指定的重启命令 - Docker 环境改了
php.ini必须重建镜像，或至少docker exec -it 容器名 /bin/sh -c "kill -USR2 1"（前提是 PHP-FPM 开了 graceful reload）
opcache.validate_timestamps 设得太大导致“改了像没改”
PHP 8.5.5 默认仍启用 OpCache，且 opcache.revalidate_freq 若设为 2（秒），意味着最多延迟 2 秒才检测文件变更——这会让开发调试显得“不生效”。
- 开发时建议设
opcache.validate_timestamps=1且opcache.revalidate_freq=0，强制每次请求都校验文件时间戳 -
opcache_reset()只清字节码缓存，不触发php.ini重解析；ini_set()对upload_max_filesize这类PHP_INI_SYSTEM级配置完全无效 - 改完配置后，必须靠重启进程让
php.ini重新加载，OpCache 只是中间一层“加速器”，不是根源
最常被忽略的是：你以为改了 php.ini 就万事大吉，其实它只是整个配置链里最底层的一环；而 phpinfo() 页面里那个 “Loaded Configuration File” 路径，才是你唯一该盯住的靶心。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
