php 加载 php.ini 时按 phprc 环境变量、编译指定路径（--with-config-file-path）顺序查找首个合法文件，scan directory 仅加载扩展专用 .ini；不同 sapi 使用不同配置，修改后须重启对应服务。
php.ini 文件到底从哪加载？
PHP 8.5 并不实际存在（截至 2024 年，最新稳定版是 PHP 8.3），但你遇到的问题本质是：PHP 启动时根本没读你改的那个 php.ini。它按固定顺序扫描多个路径，只加载第一个找到的、非空且语法合法的配置文件——后续路径哪怕有更“新”的文件，也完全被忽略。
用 php --ini 看到的 “Loaded Configuration File” 才是真正生效的那个；其他 “Scan for additional .ini files in” 路径只是用来加载扩展配置（如 opcache.ini），不参与主配置覆盖。
-
php --ini输出里第一行 “Configuration File (php.ini) Path” 是搜索起点目录，不是最终加载路径 - 真正加载逻辑是：先查
PHPRC环境变量指定路径 → 再查编译时--with-config-file-path指定目录下的php.ini→ 最后 fallback 到--with-config-file-scan-dir目录（仅用于扫描*.ini扩展配置） - Windows 下常见误操作：在
C:\Windows\放了旧版php.ini，而 CLI 实际用的是C:\php\下的，结果改了半天没反应
如何确认当前运行环境用的是哪个 php.ini？
别猜，直接问 PHP 自己。不同 SAPI（CLI / Apache / FPM）可能加载完全不同的配置文件，尤其在多版本共存或容器环境中。
- CLI 下执行：
php --ini（看 Loaded Configuration File）和php -r "echo php_ini_loaded_file();"（验证是否真加载成功） - Web 环境下，在脚本里加
phpinfo();，重点看 “Loaded Configuration File” 行，不是 “Configuration File (php.ini) Path” - FPM 场景注意：
php-fpm.conf中的php_admin_value[php_ini]或php_flag[display_errors]可能强行覆盖php.ini里的设置，优先级更高
为什么改了 php.ini 却不生效？
最常见原因不是路径错，而是“改了不该改的文件”，或者改完没重启对应服务。
立即学习“PHP免费学习笔记（深入）”；
- Apache 模块模式下，改完
php.ini必须重启httpd或apache2，仅 reload 不够；CLI 下改完要重新开终端（因为php进程启动时就读一次） - 使用
ini_set()设置的值，只对当前请求有效，无法替代php.ini全局配置（比如memory_limit在脚本里用ini_set()可能被php_admin_value锁死） - 某些发行版（如 Ubuntu 的
php8.3-cli包）会把主配置拆成两层：/etc/php/8.3/cli/php.ini（CLI）和/etc/php/8.3/apache2/php.ini（Apache），改错目录等于白改
php.ini 扫描目录（Scan Directory）到底干啥？
它不加载主配置，只加载扩展专属的 *.ini 文件，比如 opcache.ini、redis.ini。这些文件不能写全局指令（如 date.timezone），否则 PHP 启动直接报 PHP Warning: Unknown: Directive 'date.timezone' is not valid。
- 扫描目录路径由编译参数
--with-config-file-scan-dir决定，可用php --ini查看 “Scan for additional .ini files in” - 该目录下所有以
.ini结尾的文件都会被按字母序加载，所以常看到10-opcache.ini、20-redis.ini这种命名——顺序影响扩展初始化依赖 - 如果某个
*.ini文件语法错误（比如少个分号），整个扫描会中断，后续文件不加载，但 PHP 仍能启动（只是部分扩展失效）
.ini 就能调 max_execution_time，其实那地方根本不认这行。 
