先用php -m确认扩展是否真缺失，再通过php --ini核对CLI模式php.ini路径并检查extension=行；Ubuntu需按php -v版本号安装如php8.2-gd，装后重启终端验证，切勿滥用--ignore-platform-reqs。
composer install 报 “ext-xxx is missing” 怎么确认真缺还是假报
错误信息里写的 ext-gd、ext-mbstring 这类，不是建议项，是硬性依赖。但别急着装——先验证它是否真没加载：php -m | grep gd 看输出有没有 gd；php --ini 确认你查的是 CLI 模式下的 php.ini（Web 和 CLI 配置常不同）。如果 php -v 显示 PHP 8.2，但 composer.lock 里写着 "platform": {"php": "8.1.0"}，那 Composer 实际按 8.1 解析，可能误判扩展可用性。
Ubuntu/Debian 下补 ext-xxx 的正确命令格式
系统包名和 PHP 扩展名不总是一致，硬套 php-xxx 常失败：
-
sudo apt update && sudo apt search php- | grep -i gd先搜真实包名（常见是php-gd，但 PHP 8.2 可能是php8.2-gd） - 装错版本会白装：用
php -v输出的主版本号拼包名，如sudo apt install php8.2-mbstring - 装完必须重启 CLI 环境：新开终端再跑
php -m，否则缓存仍显示缺失 - 某些扩展（如
ext-imagick）还需额外库：sudo apt install libmagickwand-dev，否则编译失败
为什么加 --ignore-platform-reqs 后 install 成功但 runtime 报错
这个参数只是让 Composer 跳过校验，不等于环境真满足运行条件：
-
composer install --ignore-platform-reqs装出来的vendor/目录里，包代码存在，但运行时调用gd_info()或mb_strlen()仍会 fatal error - CI 脚本里出现这行，等于放弃环境一致性——测试通过的构建，在生产机上大概率崩溃
- 临时调试可加，但必须立刻跟一句
composer check-platform-reqs定位缺口，而不是留着参数继续跑 - 若项目真要降级兼容旧环境，该改的是
composer.json里的"require"版本约束，不是绕过检查
composer.lock 里 platform 配置怎么查、怎么删
composer.lock 中的 platform 字段是隐形开关，不显式写在 composer.json 里也能生效：
- 打开
composer.lock，搜索"platform"，看是否存在类似"platform": {"php": "8.2.10", "ext-gd": "1.0"}的块 - 它通常来自
composer.json的"config": {"platform": {...}}，删掉整个config.platform段再运行composer update --lock - 删之前确认：本地 PHP 真能跑 lock 文件里所有包。比如 lock 锁了
laravel/framework: ^10.0，而你本地是 PHP 7.4，删 platform 后install会直接失败，不是跳过 - 团队协作中，有人提交了带 platform 的 lock，别人没注意就
install，结果全队环境被“统一降级”——这种隐式约束比明写更难排查
真正麻烦的不是缺哪个扩展，而是 composer.lock 里记录的平台要求和当前机器的 PHP 版本、已加载扩展、甚至 OpenSSL 版本之间存在多层错位。手动补一个 ext-xxx 只解决表象，得顺着 composer check-platform-reqs 的输出逐条对齐，才算稳住底座。
