PHP实际加载的php.ini路径需通过php –ini或phpinfo()中的“Loaded Configuration File”确认，修改后必须重启对应服务并分别验证CLI与Web环境。
PHP本地环境改 php.ini 文件，关键不是“找到哪个文件”，而是“改对哪个文件”——因为本地开发环境（如 XAMPP、WAMP、MAMP、Docker 或手动编译）可能有多个 php.ini，而 PHP 实际加载的只有一个。
怎么确认 PHP 正在用哪个 php.ini？
直接运行 php --ini（命令行）或创建一个 info.php 文件写入 并在浏览器访问，重点看两处：
-
Loaded Configuration File：这才是 PHP 运行时真正读取的
php.ini路径 -
Scan for additional .ini files in：该目录下所有
.ini文件也会被合并加载（如opcache.ini、xdebug.ini）
别只改 XAMPP/php/php.ini 或 /etc/php/8.2/cli/php.ini ——如果 Loaded Configuration File 显示的是别的路径，改了也白改。
常见本地环境对应的 php.ini 位置
不同环境默认加载路径差异很大，改错位置是高频翻车点：
立即学习“PHP免费学习笔记（深入）”；
-
XAMPP（Windows）：通常是
XAMPP/php/php.ini，但需确认Loaded Configuration File是否指向它；Apache 模块和 CLI 可能用不同文件 -
WAMP（Windows）：右键托盘图标 →
PHP → php.ini，它会自动打开正确的那个（通常为wamp64/bin/php/php{version}/php.ini） -
MAMP（macOS/Windows）：菜单栏 MAMP →
File → Edit Template → PHP → php.ini（避免手动找错路径） -
Docker（官方
php:apache或php-cli）：容器内没有预置php.ini，需挂载或通过docker-php-ext-enable+ini文件控制；CLI 和 Apache 模块默认共用同一份，但入口不同 -
Mac（Homebrew PHP）：路径类似
/opt/homebrew/etc/php/8.2/php.ini，但每次升级 PHP 版本后路径会变，且php --ini才是唯一权威
改完 php.ini 后必须做的三件事
改了文件不等于生效，尤其本地环境常被忽略重启环节：
-
Apache/Nginx 必须重启服务：XAMPP/WAMP/MAMP 点“Restart All”；Docker 要
docker-compose restart或重建容器；Homebrew 用brew services restart httpd或nginx -
CLI 模式要验证独立生效：
php -i | grep 'memory_limit'，不能只信浏览器里phpinfo()的结果（它反映的是 Web SAPI，不是 CLI） -
注意
include_path、date.timezone等配置值带引号与否：比如date.timezone = "Asia/Shanghai"是对的，但date.timezone = Asia/Shanghai（无引号）在某些旧版本会报 Warning
为什么有些修改看起来没生效？
除了重启遗漏，还有几个隐蔽原因：
-
php.ini里某项被.htaccess或ini_set()覆盖（如memory_limit在脚本里又被设成128M） - 用了 OPcache：改完
php.ini后，OPcache 缓存的字节码可能没清，导致行为未更新；可临时加opcache.revalidate_freq=0或调用opcache_reset() - 某些扩展（如 Xdebug）有自己的
.ini文件，在Scan for additional .ini files in目录下，它们的设置优先级可能更高（例如xdebug.mode=off会覆盖zend_extension加载） - CLI 和 Web SAPI 使用完全不同的
php.ini：用php --ini和phpinfo()分别查，别混为一谈
最稳妥的做法：每次修改前先记下原始值，改完立刻用对应方式验证（php -r "echo ini_get('xxx');" 或 phpinfo() 页面搜索），而不是凭经验“应该生效了”。本地环境的多层抽象（Web 服务器 + PHP SAPI + 扩展加载机制）会让看似简单的配置变更变得不可见。