Composer 在 require 中声明 ext-xxx 会报错，是因为它仅做运行环境契约校验：若当前 PHP 环境未加载或版本不满足该扩展，就中断安装，确保部署一致性；它不负责安装扩展，需运维提前配置 php.ini 并启用。
Composer 本身不管理 PHP 动态扩展（如 ext-redis、ext-curl）的加载或启用，它只做声明式检查和环境兼容性验证。真正起作用的是 PHP 运行时和系统配置。
为什么 composer require ext-xxx 会报错？
当你在 composer.json 的 require 字段写 "ext-redis": "*"，Composer 不会去安装或编译这个扩展——它只是在 composer install 或 composer update 时检查当前 PHP 环境是否已加载该扩展及其版本是否满足约束。如果没装、没启用、或版本太低，就会报类似这样的错误：
Package <code>ext-redis</code> not found. Install it or re-run with --ignore-platform-req=ext-redis
这不是 Composer 的 bug，而是它的设计逻辑：平台依赖（ext-*、php 版本等）属于“运行环境契约”，必须由运维或 CI 环境提前保障。
- PHP 扩展是 C 编译产物，依赖系统级库（如
hiredis、openssl），Composer 没能力跨平台自动构建 -
ext-*不在 Packagist 上发布，没有composer install可执行的安装逻辑 - 即使你用
pecl install装了扩展，也得手动在php.ini里加extension=redis.so并重启 PHP 进程
如何让 Composer 正确识别已安装的扩展？
确保 Composer 能“看到”扩展，关键在于让它调用的 PHP CLI 和 Web Server 使用的是同一个 php.ini 配置，并且扩展确实已加载：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
php -m | grep redis确认扩展出现在已加载列表中 - 运行
php --ini查看 CLI 模式实际加载的php.ini路径，对比 Web 环境（如phpinfo()输出）是否一致 - 若使用 Docker，注意基础镜像是否已预装扩展（如
php:8.6-cli默认不含ext-redis，需额外docker-php-ext-install redis） - 某些扩展（如
ext-sodium）在 PHP 7.2+ 已内置，无需单独安装，但 Composer 仍会检查其存在性
绕过扩展检查的几种方式（慎用）
仅在明确知道风险且有替代方案时才考虑跳过，比如 CI 中用 stub 模拟扩展行为、或本地开发暂不启用某模块：
- 临时忽略单个扩展：
COMPOSER_DISABLE_EXTENSIONS=1 composer install - 在
composer.json中伪造平台版本（相当于告诉 Composer “我有这个扩展，版本是 X”）："config": { "platform": { "ext-redis": "5.3.7" } } - 忽略全部平台要求（不推荐）：
composer install --ignore-platform-reqs
这些操作不会让扩展 magically 出现，只是让 Composer 放行。如果代码真调用了 Redis::connect() 而扩展未加载，运行时仍会抛出 Class 'Redis' not found 或 Call to undefined function redis_connect()。
模块化项目中怎么协调扩展依赖？
像 Laravel Modules、Magento 2 或 Yii2 这类支持模块热插拔的框架，模块自身可能声明对某个扩展的强依赖（例如一个支付模块依赖 ext-openssl），但 Composer 仍只在校验阶段介入：
- 模块的
composer.json可写"ext-openssl": "^8.0"，这会阻止整个项目在不满足条件的环境中完成安装 - 模块安装后，框架启动时若检测到扩展缺失，应由模块自身的服务提供者（Provider）或初始化逻辑抛出更友好的提示，而不是等到第一次调用才崩溃
- CI/CD 流水线中建议显式检查：
php -r "if (!extension_loaded('mbstring')) exit(1);"，比依赖解析失败后的报错更早暴露问题
最易被忽略的一点：PHP 扩展的启用状态是进程级的，CLI 和 FPM 可能加载不同配置；你在终端跑 composer install 成功，不代表 Web 请求就能用 ext-gd —— 必须分别验证两个 SAPI 环境。
