应修改 phpEnv 当前版本对应配置文件，如 ~/.phpenv/versions/x.x.x/etc/php.ini 或 conf.d/realpath.ini；推荐设 realpath_cache_size=4M 以平衡性能与内存开销。
phpEnv 下找不到 php.ini 怎么改 realpath_cache_size
phpEnv 是多版本 PHP 环境管理工具，它不直接覆盖系统 php.ini，而是为每个 PHP 版本维护独立的配置目录。你用 php --ini 看到的 “Loaded Configuration File” 路径，才是当前生效的 ini 文件——通常形如 ~/.phpenv/versions/8.2.12/etc/php.ini 或 ~/.phpenv/versions/8.2.12/etc/conf.d/realpath.ini。
常见错误是直接去 /etc/php/*/cli/php.ini 或 /usr/local/etc/php/ 修改，那些对 phpEnv 启动的 PHP 进程完全无效。
- 先确认当前 PHP 版本和配置路径：
phpenv versions+php --ini - 如果
conf.d/目录存在，优先新建realpath.ini（比改主 php.ini 更安全，升级版本时不易被覆盖） - 若该目录不存在，就编辑
php.ini末尾追加配置项
realpath_cache_size 应该设多大才不浪费也不卡顿
值太小（如默认 16K 或 4M）会导致大量 stat64() 系统调用，尤其在 Composer 项目里 require 数百个文件时，每秒可能触发上千次磁盘查询；值太大（如 16MB+）则每个 PHP-FPM worker 进程都独占一份缓存，内存开销翻倍，却几乎不提升性能。
- 中小型项目（vendor 文件数 realpath_cache_size = 4096K
- 大型 Composer 项目（Laravel/Symfony 全量 vendor）：设
realpath_cache_size = 8192K - 迷你主机或 ARM 设备（如树莓派）：至少设
4096K，否则require延迟肉眼可见 - 别用
16M或32M—— 没有实测依据，纯属堆内存
为什么改了 php.ini 但 realpath_cache_size() 返回值没变
这个函数返回的是「当前已使用的缓存字节数」，不是配置上限。它只在真实路径解析发生后才增长，且受 realpath_cache_ttl 控制存活时间。所以刚改完配置，运行 php -r "echo realpath_cache_size();" 得到 0 或个位数是正常的。
立即学习“PHP免费学习笔记（深入）”；
- 要验证是否生效，得跑一段真实加载逻辑，比如
php -r "require 'vendor/autoload.php'; echo realpath_cache_size();" - 更可靠的方式是用
strace -e trace=stat64 php your_script.php 2>&1 | grep -c stat64对比修改前后的调用次数 - 注意：CLI 和 FPM 的配置文件通常不同，FPM 还要重启
php-fpm进程才能加载新值
realpath_cache_ttl 和 opcache.validate_timestamps 必须配对调整
这两个参数看似无关，但协同失效时会引发隐蔽 I/O 暴增。典型症状是开发环境改了文件却 require 失败，或生产环境 CPU 突然飙高、响应变慢。
- 开发环境：设
realpath_cache_ttl = 5+opcache.validate_timestamps = 1，保证改即生效 - 生产环境：必须设
realpath_cache_ttl = 7200（2 小时） +opcache.validate_timestamps = 0，否则 opcache 不检查文件变更，而 realpath 缓存又频繁过期重查，反而制造更多stat64 - 单独调大
realpath_cache_size却忽略ttl配置，等于只修水管不关阀门
strace 验证 stat64 是否真减少。缓存大小只是表，I/O 行为才是里。 
