Composer不安装PHP扩展，仅在install/update时校验require或require-dev中声明的ext-*是否已加载且版本匹配；缺失则立即报错中断，而非运行时报错。
Composer 本身不安装、不编译任何 PHP 扩展，它只校验 ext-* 是否已加载且版本匹配；声明错误或环境缺失，会在 composer install 阶段直接报错中断，而不是等到运行时报 Call to undefined function。
ext-* 必须写在 require 或 require-dev 里，不能放其他字段
很多人误以为 config.platform 是声明扩展的地方，其实不是——config.platform 只用于“假装”扩展存在，是绕过检查的临时手段，不是正向声明。真正起约束作用、触发校验逻辑的，只有 require 和 require-dev 下的 ext-xxx 条目。
-
ext-curl、ext-pdo_mysql、ext-mbstring等必须小写，与php -m输出完全一致（不含下划线、无版本后缀） - 版本号只能是
"*"、""（等价于"*"），或语义化版本如"^1.4"、">=1.0"；"^7.4"或"1.0.0"这类写法无效，Composer 不报错但会静默忽略版本约束 - 开发专用扩展（如
ext-xdebug）应放进require-dev，否则composer install --no-dev仍会因缺失而失败
ext-* 校验发生在 install/update 时，不等于运行时可用
Composer 检查的是 extension_loaded('curl') 是否返回 true，以及 phpversion('curl') 是否满足约束。但它不关心扩展是否被正确启用（比如 php.ini 里注释掉了 extension=curl.so）、也不验证函数签名兼容性。
- 常见错误：Docker 构建中先跑
composer install，再装扩展 → 报ext-curl not found；正确顺序是先用apt install php-curl或docker-php-ext-install curl，再执行 Composer 命令 - Windows 用户需确认 php.ini 中已取消注释对应行（如
extension=php_curl.dll），且 DLL 文件存在于ext/目录 -
config.platform设成"ext-redis": "5.3.7"可让composer install通过，但若实际没装redis.so，PHP 运行时仍会崩在new Redis()
某些扩展的版本号根本不可靠，约束要谨慎
像 ext-json、ext-pcre 这些内置扩展，PHP 版本升级时可能带新行为，但 phpversion('json') 通常返回空或固定字符串（如 "1.4.0"），并不随 PHP 小版本变化。强行写 "^1.5" 可能导致本地通过、CI 失败，或反过来。
- 优先用
"*"，除非你明确依赖某个函数（如json_validate()要求 json >= 1.6） -
ext-openssl的版本号来自 OpenSSL 库本身，不是 PHP 绑定层，phpversion('openssl')返回的可能是"101010cf"这类十六进制，语义化约束基本失效 - 不确定时，用
php -r "var_dump(extension_loaded('xxx')); var_dump(phpversion('xxx'));"实测目标环境输出再定约束
最容易被忽略的一点：扩展声明不是“可有可无的文档”，而是运行契约。一旦写进 require，就意味所有部署节点都必须满足——包括 CI runner、容器镜像、甚至 serverless 函数的底层 runtime。漏掉一个 ext-gd，图片处理逻辑上线就哑火，而错误堆栈里不会告诉你缺了啥，只会抛出模糊的 Class 'Imagick' not found 或 imagecreatefrompng(): Failed to load。
