config.platform是唯一靠谱的项目级PHP版本模拟方式，必须写在composer.json的config对象内且值为平台对象，仅影响依赖解析，不改变运行时环境。
config.platform 是唯一能稳定控制 Composer 依赖解析时“假装环境”的方式，必须写在项目 composer.json 的 config 字段内，且值为对象；写错位置、类型或漏扩展，composer install 就可能装错包，线上直接报 Fatal error。
platform 必须嵌套在 config 对象里，不能是顶层字段
很多人复制粘贴时把 platform 直接写在 composer.json 根层级，结果完全不生效。Composer 只认 "config": { "platform": { ... } } 这个路径。
- ✅ 正确结构：
"config": { "platform": { "php": "8.1.25", "ext-mbstring": "*" } }，和require同级 - ❌ 错误写法：
"platform": { "php": "8.1.25" }（顶层，被忽略） - ❌ 错误写法：
"config": { "platform.php": "8.1.25" }（键名非法，Composer 不识别） - ❌ 错误写法：
"config": { "platform": "8.1.25" }（值必须是对象，字符串会静默失效）
只设 php 版本远远不够，扩展必须手动列全
Composer 不读你的 php.ini 或 php -m 输出，它只看你明确写进 config.platform 的项。漏一个，就可能让 composer update 选中依赖该扩展但你生产环境没启用的包。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 常见必填扩展：
"ext-mbstring": "*"、"ext-openssl": "*"、"ext-json": "*"、"ext-sodium": "*" - 扩展名严格匹配
php -m输出：是ext-xdebug，不是xdebug或php-xdebug - 版本号建议写具体小版本（如
"8.1.25"），避免"^8.1"被解析成 8.1.99 导致误判 - 如果某包 require
"ext-gd": "^8.0"，而你没声明ext-gd，install 就会失败
改完 platform 后，必须重解依赖树才能生效
composer.json 里改了 config.platform，但 composer.lock 还缓存着旧解析结果，composer install 会直接复用——等于白改。
- 最稳妥做法：删掉
composer.lock和vendor/，再运行composer install - 或者强制重解：
composer update --with-all-dependencies - 验证是否生效：
composer config --list | grep platform，看到带(local)标记才算对 - 调试时可临时加
--ignore-platform-reqs，但它绕过所有约束，仅限定位问题，CI/CD 绝对禁用
platform 不影响运行时，只管 install/update 阶段的包选择
哪怕你设成 "php": "7.4.0"，本地 PHP 8.3 依然能跑起来——但只要代码用了 match 表达式，部署到真 PHP 7.4 环境就必然崩。这是最容易被忽略的一点：platform 是编译期声明，不是运行时切换。
- 它不改变
php -v输出，也不调用别的 PHP 二进制 - 它不安装或启用任何扩展，只是告诉 Composer：“就当这些扩展已存在”
- 真实环境没装
ext-sodium，即使 platform 声明了，运行时仍会报Class 'SodiumException' not found - 宝塔或多 PHP 环境下，务必确认
which php和php -m对应的是目标版本，否则 platform 再准也救不了函数不存在的问题
