PHP启动提示“PHP startup”警告的解决方法是将php.ini中extension_dir设为绝对路径，如extension_dir = "D:/myphpenv/php5.4/ext"，并确保路径真实存在、扩展文件名与PHP版本ABI匹配，最后重启Web服务器（如Apache或PHP-FPM）使配置生效。
phpEnv 下 extension_dir 路径必须写绝对路径
phpEnv 默认会把 extension_dir 设成相对路径（比如 "ext"），但 PHP 实际加载时不会自动拼接 PHP 安装根目录，而是按当前工作目录去找——这在 CLI 和 Web SAPI 下行为不一致，极易静默失败。
你看到 php -m 里没扩展、phpinfo() 不显示，大概率就是这个原因。
- 运行
php --ini确认正在读哪个php.ini - 打开它，找到
extension_dir行，改成完整路径，例如：extension_dir = "/phpenv/versions/8.1.26/lib/php/extensions/no-debug-non-zts-20210902" - 路径必须真实存在，且该目录下有
curl.so、mbstring.so等文件 - 别用波浪号
~或环境变量，PHP 不解析它们
phpEnv 重启服务 ≠ reload，必须 stop + start
phpEnv 自带的 phpenv restart 或 phpenv reload 命令往往只重载配置，不真正重启 PHP-FPM 进程，导致 php.ini 修改不生效。
尤其当你改了 extension_dir 或新增了 extension= 行，旧进程仍拿着旧配置在跑。
立即学习“PHP免费学习笔记（深入）”；
- 先查 PHP-FPM 进程：运行
ps aux | grep php-fpm，确认主进程 PID - 手动停掉：用
kill -USR2 <pid></pid>不可靠，直接kill -9 <pid></pid>再启动 - 或更稳妥：进入 phpEnv 的 PHP 版本目录，执行
bin/php-fpm -t校验配置，再bin/php-fpm启动 - Web 请求走的是 FPM，不是 CLI，所以
php -v正常不代表网页环境 OK
CLI 和 Web 环境用的是两套 php.ini
phpEnv 默认为 CLI 和 FPM 分别生成配置文件，php --ini 显示的 Loaded Configuration File 路径，和 phpinfo() 里看到的几乎总是不同。
你在命令行里 php -m | grep curl 看到了，不代表浏览器访问时也启用了——因为 FPM 加载的是另一份 php.ini。
- 建一个
info.php，内容为<?php phpinfo(); ?>，浏览器打开后搜索 “Loaded Configuration File” - 对比它和
php --ini输出的路径，两个文件都要检查extension=行是否开启、路径是否正确 - phpEnv 的 FPM 配置通常在
~/.phpenv/versions/8.1.26/etc/php-fpm.d/www.conf，里面可能指定php_admin_value[php_ini]覆盖默认路径
扩展文件名后缀和架构必须严格匹配
phpEnv 编译的 PHP 是 ZTS 还是 Non-ZTS、线程安全与否、PHP ABI 版本（如 20210902），都决定了扩展文件名和兼容性。错一个就加载失败，且不报错。
比如你装的是 PHP 8.1.26（ABI 20210902），但放进去的是为 PHP 8.2 编译的 redis.so，或者文件名写成 redis.dll（Windows 才用），PHP 就直接跳过。
- 确认 ABI 版本：运行
php -i | grep "PHP Extension Build"，看输出类似API20210902,NTS - 扩展文件名应为
xxx.so（Linux/macOS）或xxx.dll（Windows），不能混用 - 扩展路径里不能有空格或中文，某些版本会截断
- 用
file /path/to/redis.so确认是与 PHP 同架构（x86_64 vs aarch64）的动态库
phpinfo() 页面有没有“curl”字样——那只是加载成功；还要在脚本里写 var_dump(function_exists('curl_init'));，返回 true 才算真正可用。很多扩展加载了但依赖缺失（比如 cURL 没配 curl.cainfo），函数调用照样失败。 
