Composer v2不自动向下兼容，需精确配置config.platform（如"php":"7.4.33"）、列全扩展、执行composer update --with-all-dependencies，并配合require中显式版本约束（如"guzzlehttp/guzzle":"6.5.5"）才能确保旧PHP环境兼容。
Composer 新版本（v2.x）本身不提供对旧版 PHP 或旧包的“向下兼容处理”能力——它只按你声明的约束和平台配置去选包，不会自动降级、桥接或 polyfill。 真正起作用的是你如何写 composer.json、怎么设 config.platform、以及是否用对了 composer update 参数。下面分几个实操关键点说清楚。
platform 配置必须写死小版本号，否则形同虚设
只写 "php": ">=7.4.0" 没用，Composer v2 会无视它，直接挑最新兼容包（比如 PHP 8.1+ 才能跑的 monolog/monolog v3）。真正生效的是精确到小版本的 config.platform.php：
-
"php": "7.4.33"—— 必须是你目标环境实际运行的版本，不是7.4或^7.4 - 所有用到的扩展也得列全：
"ext-mbstring": "7.4.33"、"ext-openssl": "7.4.33"等 - 改完后必须执行
composer update --with-all-dependencies，否则composer.lock仍含高版本包
require 中的版本约束要配合 platform 才有效
单独写 "guzzlehttp/guzzle": "^6.5" 在 PHP 7.4 下可能装到 6.5.9（支持），但若没设 platform，Composer v2 可能跳过它、去装 7.4.5（要求 PHP 7.2.5+），结果在 PHP 7.4.33 上报 ParseError。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐显式锁定已验证兼容的版本：
"guzzlehttp/guzzle": "6.5.5" - 查 Packagist 确认该版本的
requires php字段是否匹配你的platform.php - 避免用
^1.23这类宽松约束——1.28.0可能已放弃 PHP 5.4 支持
composer update 不会自动重算平台兼容性，得手动触发
PHP 版本升级后，composer update 默认仍沿用 composer.lock 里为旧 PHP 解出的包版本。它不会主动检查“这些包现在还适配吗？”
- 执行
composer update --with-all-dependencies是必须步骤，否则间接依赖（如psr/log）仍卡在旧版 - 不要用
--ignore-platform-reqs临时绕过——它会让 Composer 装上语法不兼容的包，运行时报错更难定位 - 升级 PHP 后建议先跑
composer clear-cache，再composer update --with-all-dependencies
老项目中已装高版本包，不能靠 install 回退
composer install 只读 composer.lock，不会校验当前装的包是否超出 require 范围。如果 lock 文件里是 monolog/monolog v2.10.0，而你想退回 v1.27.2，就得主动干预：
- 先删掉原声明：
composer remove monolog/monolog - 再指定版本重装：
composer require monolog/monolog:1.27.2 - 失败时看报错链，用
composer why-not monolog/monolog:1.27.2定位哪个依赖在阻止它
最易被忽略的一点：platform 配置只影响 update 阶段的依赖解析，不影响 runtime。就算你设了 "php": "8.1.0"，实际用 PHP 7.4 运行，照样会 Fatal error——它骗不了 PHP 解析器。
