根本原因是composer默认启用平台扩展检查，发现php.ini未启用ext-xxx即中断安装；可用--ignore-platform-req=ext-xxx精准跳过单个扩展校验，保留php版本等其他检查。
composer install 报 ext-xxx 缺失，但你确定不需要它
根本原因是 Composer 默认启用平台扩展检查（platform requirements），发现 php.ini 里没启用某个扩展（比如 ext-gd、ext-redis），就中断安装。这不是依赖冲突，而是校验环节的硬性拦截。
- 最常用解法是加
--ignore-platform-req=ext-gd—— 只跳过对ext-gd的检查，其他扩展和 PHP 版本仍会校验 - 想跳过多个扩展，重复使用参数：
--ignore-platform-req=ext-imagick --ignore-platform-req=ext-curl - 注意：这个参数只影响当前命令，不会改
composer.json或composer.lock，也不会让扩展真的“存在” - 如果代码里写了
new Redis()，而系统没装ext-redis，运行时照样报Class 'Redis' not found
什么时候该用 --ignore-platform-req=ext-xxx，而不是 --ignore-platform-reqs
用 --ignore-platform-reqs 是全局跳过所有平台检查（PHP 版本 + 所有扩展 + lib 库），风险高；而精准忽略单个扩展更安全，尤其当你只缺一个非核心扩展、又想保留 PHP 版本校验时。
- CI/CD 中本地构建环境缺
ext-igbinary，但生产环境有 → 用--ignore-platform-req=ext-igbinary - 项目要求
"php": "^8.1"，你本地是 8.2，但还报ext-mbstring缺失 → 只加--ignore-platform-req=ext-mbstring，不碰 PHP 校验 - 某些包把
ext-xxx放在require里，其实只是可选功能（如monolog/monolog对ext-amqp）→ 精准忽略比全关更贴近真实需求
为什么加了 --no-scripts 还是卡在 ext 检查
--no-scripts 只禁用 scripts 字段定义的钩子（如 post-install-cmd），和平台校验完全无关。校验发生在依赖解析之后、脚本执行之前，属于 Composer 安装流程的硬性前置步骤。
- 如果你加了
--no-scripts仍失败，说明问题不在脚本，而在平台校验本身 - 常见诱因包括：
ext-igbinary在旧版 PHP 上尝试加载失败后 hang 住，或disable_functions禁用了shell_exec导致内部调用失败 - 此时唯一有效解法仍是
--ignore-platform-req=ext-xxx，或手动删掉引发问题的platform声明项
config.platform 伪造扩展 vs 命令行参数，哪个更合适
在 composer.json 的 config.platform 下写 "ext-gd": "1.0" 是持久化“欺骗”Composer，让它认为扩展已存在；而命令行参数只作用于单次执行。两者本质都是绕过校验，不是解决缺失。
- 适合 CI 构建或 Docker 多阶段构建 → 用命令行参数，干净、无副作用
- 项目长期需要模拟某环境（如测试无 GD 的降级路径）→ 改
composer.json，但必须加注释说明用途 - 别用
composer config --global platform.ext-gd 1.0，会污染所有项目，极难排查 - 伪造后
composer install成功，不代表能跑通；Laravel 的服务提供者可能在容器启动时才真正检查扩展，那时报错堆栈更隐蔽
install 阶段，而是在第一次调用相关类或函数时才暴露，且错误位置离实际缺失点很远。
