config.platform必须写在composer.json根级config对象内，键名为platform且值为对象（如"php":"8.1.10"），写错位置、类型或格式均静默失效；改后须删除composer.lock和vendor再执行install/update才生效。
config.platform 写在哪才生效
必须写在 composer.json 的根级 config 对象里，键名是 platform，值必须是对象——不是字符串、不是布尔值、不能嵌套在 extra 或其他字段下。
常见无效写法：
-
"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", "ext-gd": "8.1.0" } }。这个配置会提交进 Git，所有成员和 CI 都按同一靶心选包。
为什么改了 config.platform 还是装错包
因为旧的 composer.lock 文件还在，它记录的是上次解析时的平台快照，不会自动更新。Composer install 优先读 lock 文件，完全跳过 platform 校验逻辑。
必须执行以下两步才能让新配置生效：
- 删掉现有
composer.lock - 删掉
vendor/目录 - 再运行
composer install或composer update --lock
CI 构建中更推荐用命令行参数覆盖：composer install --platform=php:8.1.10 --platform=ext-gd:true。它不污染项目配置，且每次构建都显式对齐目标环境。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
ext-* 声明怎么写才真正起作用
写 "ext-gd": "8.1.0" 比 "ext-gd": true 或空字符串靠谱得多——前者明确要求扩展 ABI 与 PHP 主版本对齐，避免因扩展二进制不兼容导致运行时 segfault；后者会被 Composer 静默忽略。
关键点：
- 只声明项目真实依赖的扩展，别堆砌一堆“可能有用”的
- 版本号必须和
php字段主版本一致（如php: "8.1.10"→ext-gd: "8.1.0"） - 不解决运行时缺失问题：
config.platform只影响安装阶段选包逻辑，不装扩展、不报错、不校验真实环境
如果线上缺 ext-gd，composer install 仍会成功（只要 lock 文件允许），但脚本一调用 imagecreatefrompng() 就 fatal error。
--ignore-platform-reqs 是临时止痛药，不是解药
它跳过所有平台检查，包括 php 版本、ext-*、lib-*，风险极高：
- 可能装入含 PHP 8.2 语法（如
match表达式）的包，而你本地是 PHP 8.1，运行即ParseError - 可能导致
vendor/autoload.php生成异常——比如装了本不该装的 polyfill 版本，autoload classmap 漏掉关键路径 - CI 脚本里滥用等于主动放弃环境一致性防线
真要用，也应限制范围：composer install --ignore-platform-req=ext-igbinary 比全局忽略安全得多。但更好的做法是：提前在 composer.json 中用 config.platform 显式声明目标扩展，让依赖解析阶段就避开强依赖项。
最易被忽略的点：platform 配置不写入 composer.lock，所以它只影响解析行为，不固化到锁文件里——这意味着每次 composer install 都得靠配置或参数重新触发，否则就回归真实环境。
