线上环境包不一致的根源是 composer.json 缺失或错误配置 config.platform，正确写法为 "config": { "platform": { "php": "8.1.10" } }，且须删除旧 composer.lock 和 vendor 后重装；CI 中必须显式使用 --platform=php:8.1.10 参数。
线上跑不起来，不是“环境不同”这种模糊归因，而是 composer.json 里缺了 config.platform，或者写了但被旧 composer.lock 覆盖了——这直接导致云端编译选包逻辑和本地不一致。
platform 配置必须写在根级 config 下，且值是对象
常见错误是把配置塞错位置，结果 Composer 完全忽略：
-
"config": { "platform.php": "8.1.10" }❌ 键名错，Composer 不识别 -
"extra": { "platform": { "php": "8.1.10" } }❌ 层级错，不生效 -
"config": { "platform": "8.1.10" }❌ 值必须是对象，字符串被跳过 -
"config": { "platform": { "php": "^8.1" } }❌ 版本号必须是具体小版本（如"8.1.10"），否则被忽略
正确写法只有一种："config": { "platform": { "php": "8.1.10" } }
删掉旧 composer.lock 和 vendor/ 再重装
config.platform 只影响 composer install 和 composer update 时的解析行为，它不会覆盖已存在的 composer.lock。旧锁文件会继续按原来平台解析，导致你改了配置也白搭。
实操步骤必须是：
- 删除项目根目录下的
composer.lock - 删除
vendor/目录 - 运行
composer install或composer update --lock
执行完后用 composer show php 确认当前解析用的 PHP 版本是否为你设定的值。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
CI 中用 --platform=php:x.y.z 而不是改项目配置
CI 环境不可信，不能依赖它预装的 PHP 版本或全局 composer.json。每次构建都应显式指定平台版本：
-
composer install --no-interaction --platform=php:8.1.10✅ Composer 2.2+ 支持，推荐 -
--ignore-platform-req=php❌ 跳过校验但不保证兼容，上线 runtime 报错更难排查
如果用 Docker，Dockerfile 中应固定 Composer 版本并带上该参数：RUN composer self-update 2.5.8 && composer install --no-interaction --platform=php:8.1.10
为什么 vendor 里还是装了 PHP 8.2 专属的包？
platform 不会阻止你装一个本身只兼容 8.2 的包——只要它的 require 声明允许（比如 "php": "^8.2"），而你的 platform.php 又设成了 "8.2.5"，它就会被选中。
所以还得检查依赖包本身的 PHP 约束：
- 运行
composer show vendor/pkg | grep php查看该包声明的 PHP 要求 - 确认你依赖的包是否真用了宽松约束（如
"^8.1"），而不是只支持高版本 - 若某包硬要求
php: ^8.2，而你平台设的是8.1.10，那它根本不会进锁文件——此时报错才是正常行为
真正容易被忽略的是：platform 不写入 composer.lock，所以 CI 每次都要带 --platform 参数；不带，就等于没设。
