加 --ignore-platform-reqs 参数可跳过平台要求检查，但需确保 composer.lock 与目标环境 PHP 版本一致，且扩展真实可用；推荐在统一环境中生成 lock 文件并打包 vendor 部署。
composer install 时提示 platform requirements 不满足怎么办
离线环境里 composer install 报错 Your requirements could not be resolved to an installable set of packages，大概率是它在检查 PHP 版本、扩展（如 ext-gd）或平台包（如 php、ext-mbstring）时失败了——而你根本没法装这些扩展，或者目标服务器的 PHP 版本就是低的。
这不是依赖冲突，是 Composer 默认做的一层“安全校验”。关掉它，才能让锁文件里的包照常解压安装。
- 加
--ignore-platform-reqs参数：跳过所有平台要求检查（PHP 版本、扩展、平台包） - 更细粒度控制用
--ignore-platform-req+ 具体项，比如--ignore-platform-req=php或--ignore-platform-req=ext-gd - 注意：这个参数只影响
install和update，对require无效；且不会改写composer.lock，只是绕过校验
为什么 --ignore-platform-reqs 不总能解决问题
用了 --ignore-platform-reqs 还报错？常见原因是：你本地生成的 composer.lock 本身依赖高版本 PHP 或扩展，而目标环境连基础运行都撑不住——比如锁文件里用了 PHP 8.2 的语法，但服务器只有 PHP 7.4。
这时候不是 Composer 拦着你，是代码真跑不起来。
- 确认
composer.lock是在与目标环境一致的 PHP 版本下生成的（推荐在 CI 或 Docker 中固定 PHP 版本生成 lock） -
--ignore-platform-reqs不解决运行时错误，只解决安装阶段的“拒绝安装” - 如果项目用了
platform配置（composer.json里的"platform": {"php": "7.4.0"}），它会覆盖实际 PHP 版本，此时要同步调整该配置
离线部署时怎么避免反复踩坑
真正稳定的离线流程，不是每次靠 --ignore-platform-reqs 硬扛，而是把平台约束提前对齐。
- 开发机和目标服务器用相同 minor 版本的 PHP（如都是 8.1.x），避免语法/函数级不兼容
- 在
composer.json中显式声明"config": {"platform": {"php": "8.1.25"}}，让所有环境按这个“虚拟平台”解析依赖 - 离线前先跑一次
composer install --dry-run --ignore-platform-reqs，看是否真能解出包（不下载，只模拟） - 把
vendor/打包带上，比反复install更可靠；若必须 install，确保composer.lock已提交且未被修改
容易被忽略的细节：ext-* 要求和实际加载状态不一致
有些扩展（比如 ext-redis）在 php.ini 里写了 extension=redis.so，但没重启 PHP-FPM 或 CLI 就直接跑 composer install，结果 Composer 检查时读不到，误判为缺失。
而你加了 --ignore-platform-reqs 强行装完，运行时却因扩展没加载而报 Class 'Redis' not found。
- 用
php -m | grep redis（CLI）或phpinfo()（Web）确认扩展真实可用 - CLI 和 Web SAPI 的
php.ini通常不是同一个文件，别只改了一个 -
composer show --platform可查看当前 Composer 读到的平台信息，用于交叉验证
事情说清了就结束。
