composer不控制php ini设置，错误源于cli模式下的php.ini配置；需用php --ini和php -m检查路径与扩展，可通过php -c指定ini文件或修改默认cli配置。
Composer 本身不控制 PHP 的 ini 设置，它只在当前 PHP 运行环境中执行。如果你的某个依赖包（比如 ext-gd、ext-mbstring 或要求 memory_limit > 512M 的工具）启动时报错，问题一定出在 Composer 执行时所用的 PHP 配置上，而不是 composer.json 能声明解决的。
为什么 composer install 报 “Class not found” 或 “extension missing”？
这类错误往往不是包没装好，而是 Composer 在安装/加载时调用了需要特定扩展或配置的代码（例如某些 autoload-dev 中的测试类、插件的 PluginInterface 实现，或 require-dev 里的静态分析工具）。此时实际运行的是 php 命令本身，它读取的是 CLI 模式下的 php.ini。
- 运行
php --ini查看 CLI 加载的配置路径，不是 Apache/Nginx 的php.ini - 运行
php -m确认mbstring、xml、json等基础扩展已启用（Composer 自身就依赖它们） - 如果用
php -v发现版本低于依赖要求（如某包要求php >= 8.1），composer install会直接拒绝，但不会提示“ini 错误”
如何让 Composer 使用指定 php.ini 文件？
你不能在 composer.json 里写“请用这个 ini”，但可以控制它调用哪个 php 可执行文件 —— 而这个可执行文件可以绑定自己的配置。
- 用
php -c /path/to/custom.ini composer.phar install显式指定 ini 文件 - 为不同项目创建封装脚本，比如
bin/composer：#!/usr/bin/env bash php -c "$(dirname "$0")/../conf/php-cli.ini" "$(dirname "$0")/../composer.phar" "$@"
- 修改系统默认 CLI
php.ini（通常在/etc/php/*/cli/php.ini或$(php -r "echo dirname(dirname(PHP_CONFIG_FILE_PATH));")/cli/php.ini），确保extension=和memory_limit满足所有常用依赖需求
哪些依赖会因 INI 设置失败？常见场景与检查点
不是所有包都敏感，但以下几类最容易暴露配置问题：
立即学习“PHP免费学习笔记（深入）”；
-
PHP 扩展类依赖：如
league/flysystem-aws-s3-v3不报错，但它的require里有aws/aws-sdk-php，而后者在初始化时可能触发ext-curl或ext-json检查 —— 若这些扩展未启用，composer dump-autoload都可能失败 -
开发时工具链：如
phpunit/phpunit、phpstan/phpstan启动时会校验max_execution_time、opcache.enable；若opcache.enable_cli=0（默认），PHPStan 8+ 会警告并降级行为 -
自动加载器触发逻辑：某些包在
autoload的files或psr-4类加载过程中执行function_exists()检查（如iconv），此时若ext-iconv未开启，composer install会中止
最常被忽略的是：你在 Web 服务器里开了 ext-redis，但 CLI 下没开 —— composer require predis/predis 成功，可一旦跑 php artisan tinker 或 vendor/bin/phpunit 就报 Class 'Redis' not found。环境检查永远要以 php -m 和 php --ini 为准，而不是假设“Web 能跑，CLI 就能跑”。
