应使用--platform=php:X.Y.Z或--platform=ext-xxx:V参数，它在install/update阶段均生效且优先级最高；可叠加多个，如--platform=php:8.2.10 --platform=ext-pdo:8.2.10；config.platform仅影响update，对install无效。
composer install 时怎么指定 PHP 和扩展版本
用 --platform 参数最直接有效，它在 install 和 update 阶段都起作用，且优先级高于 composer.json 里的 config.platform。这不是“伪装”，而是告诉 Composer：“按这个环境能力去解析依赖”，避免因本地 PHP 版本或扩展版本不匹配导致 Your requirements could not be resolved。
-
composer install --platform=php:8.1.20：让 Composer 认为运行环境是 PHP 8.1.20，影响所有隐式依赖（如ext-mbstring、ext-xml的兼容性推导） -
composer install --platform=ext-zip:1.2.0：单独覆盖某个扩展版本，比--platform=php:*推导出的默认值优先级更高 - 可叠加多个：
composer install --platform=php:8.2.10 --platform=ext-pdo:8.2.10 --platform=ext-curl:8.2.10
为什么 config.platform 在 install 时基本没用
composer.json 中的 "config": {"platform": {...}} 只在 composer update 时参与根项目依赖求解，对 install 阶段无效——因为 install 直接读 composer.lock，而 lock 文件里记录的是当时 update 所用的平台信息。如果你在高版本 PHP 上生成了 lock，再拿到低版本环境 install，即使 config.platform 写了 php:8.1，Composer 仍会校验当前真实环境是否满足 lock 中记录的扩展要求，失败就报错。
- 真正可控的方式只有命令行
--platform -
config.platform适合长期固定开发/部署目标环境的项目，但不能解决跨环境安装问题 - CI/CD 脚本中务必用
--platform，别依赖配置文件
如何跳过某个扩展的检查（临时绕过）
某些 CI 环境或容器里缺扩展（比如没装 ext-pcntl），但你又不想改业务逻辑，可用两种方式“假装”它存在或不存在：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 设成假版本：
"config": {"platform": {"ext-pcntl": "0"}}—— Composer 会认为该扩展版本为0，从而跳过所有要求ext-pcntl:*的包 - 用环境变量全局禁用：
COMPOSER_DISABLE_EXTENSIONS=1 composer install—— 这会让 Composer 完全忽略所有ext-*检查，风险较高，仅限测试 - 注意：
ext-*必须是包自身composer.json显式声明的依赖才生效；如果包没写"require": {"ext-posix": "*"}，那怎么配 platform 都不影响安装
常见错误：版本写错、符号混淆、漏冒号
写错一个字符，--platform 就不生效，还容易误以为是 Composer bug：
- 漏掉
=：写成--platform php:8.1（少等号）→ 参数被忽略 - 多空格：
--platform = php:8.1→ 解析失败，报Could not parse platform constraint - 版本带
v前缀：--platform=php:v8.1→ 不识别，必须是8.1或8.1.20 - 扩展名大小写错：
--platform=ext-MBSTRING:1.0→ 应为小写ext-mbstring，PHP 扩展名全小写
实际部署前最好在目标环境镜像里跑一次 composer install --dry-run --platform=... 验证是否真能解析出预期包，别只信本地测试结果。
