composer install不启用php扩展，因其职责仅限于读取composer.lock、下载vendor包和生成自动加载文件；扩展是否生效取决于php运行时环境是否通过php.ini加载对应模块，而非composer管理。
因为 composer install 本身不启用 PHP 扩展，它只管理 PHP 代码包；扩展是否生效，完全取决于 PHP 运行时环境是否加载了对应模块。
为什么 composer install 不管扩展启用这件事
composer install 的职责是：读取 composer.lock，下载 vendor 包，生成自动加载文件。它不会、也不能修改 PHP 配置或加载扩展——那是 PHP 解释器启动时由 php.ini 控制的。
常见误解是以为“装了 ext-redis 包”就等于“PHP 能用 redis 扩展”，其实 Composer 安装的是 PHP 编写的 Redis 客户端类库（如 predis/predis），而 ext-redis 是 C 编写的原生扩展，两者完全不同。
-
ext-xxx类错误（如ext-swoole、ext-gd）永远不是 Composer 没装对，而是 PHP 环境没配好 - 错误信息里明确写的是
it is missing from your system，不是not found in vendor - 即使
composer install成功，只要php -m | grep xxx没输出，运行时照样报错
怎么确认某个 ext 是否真被 PHP 加载了
别只看 php.ini 里有没有 extension=xxx，得验证 CLI 运行时状态：
- 运行
php -m | grep redis（把redis换成你要查的扩展名）——无输出 = 未加载 - 运行
php -i | grep "Loaded Configuration File"，确认你编辑的php.ini就是 CLI 实际加载的那个 - 某些扩展（如
openssl）还需额外验证功能：php -i | grep "OpenSSL Support"必须返回enabled - Windows 下还要检查
php_openssl.dll存在、extension_dir正确、且libssl-1_1-x64.dll等依赖 DLL 在 PHP 目录下
不同环境启用扩展的典型操作差异
同一句 extension=redis.so 在不同系统生效方式完全不同：
- Ubuntu/Debian：
sudo apt install php-redis（自动写配置并启用），然后重启php-fpm或 Apache - macOS + Homebrew：
brew install php@8.2-redis，再手动追加echo "extension=redis.so" >> /opt/homebrew/etc/php/8.2/php.ini - Docker Alpine：
RUN apk add php82-pecl-redis && docker-php-ext-enable redis（顺序不能反） - Windows XAMPP：
php.ini中取消注释extension=php_redis.dll，不是extension=redis，且确保php_redis.dll文件真实存在于ext/目录
最常被忽略的一点：CLI 和 Web SAPI 使用不同的 php.ini，而 composer install 走的是 CLI 模式——你改了 Apache 的 php.ini，对 Composer 完全无效。
