config.platform 是 Composer 的配置项，用于在依赖解析阶段模拟目标 PHP/扩展版本，仅影响 composer install 和 update 的包版本选择，不改变本地环境、不干预运行时行为。
config.platform 是什么，它到底在哪个环节起作用
它只影响 composer install 和 composer update 的依赖解析阶段，不改变本地 PHP 版本、不屏蔽语法、不加载或禁用扩展。Composer 解析器会拿你写的 config.platform 值去比对每个包的 require 声明（比如 "ext-pcntl": "*" 或 "php": "^8.1"），然后决定“这个包版本能不能放进解空间”。一旦解析完成，后续下载、安装、autoload 生成全按这个结果走。
常见误操作：
– 在 PHP 8.2 环境里设 "php": "8.1"，结果装完运行时报 ParseError: readonly —— 因为 config.platform.php 不拦语法，只拦包版本选择
– 本地没装 ext-gd，却设 "ext-gd": "1.0"，以为能跳过依赖检查 —— 实际上这只会让 Composer “假装”有这个扩展，但运行时仍会因缺失而失败
怎么写 config.platform 才真正生效
必须写在 composer.json 的 config 对象内，不是根级字段；且只对上游包自己声明了 ext-xxx 或 php 依赖的包起作用。
-
config.platform.php必须带小版本号，例如"8.1.10"，不能只写"8.1"，否则某些包（如ramsey/uuid）会因语义化版本解析偏差选错版本 -
config.platform.ext-xxx写法有效，但仅当目标包的composer.json明确写了"require": {"ext-xxx": "*"}才触发过滤；否则完全忽略 - 删除配置要用
composer config --unset config.platform.php，漏掉--unset会导致整个config对象被覆盖为空对象 - 若本地 PHP 版本低于
config.platform.php值，Composer 会直接报错退出，不给你“假装”的机会
为什么 platform 配置常被当成“条件安装”，其实不是
Composer 本身没有 os、platform-os 这类字段，也不读取 PHP_OS_FAMILY 或环境变量。所谓“只在 Linux 安装 ext-inotify”，本质是：包作者在自己的 composer.json 里写了 "require": {"ext-inotify": "*"}，而这个扩展在 Windows 上不可用 → Composer 在 Windows 上找不到满足条件的发行版，自然跳过。
所以 config.platform 的真实能力只是“模拟”，不是“条件”。它唯一可控的路径是：
– 你设 "platform": {"php": "8.1.10", "ext-pcntl": "1.0"}
– 某个包声明了 "require": {"php": "^8.2", "ext-pcntl": "*"} → 被排除
– 另一个包只声明 "require": {"php": "^8.1"} → 被保留
但如果你的项目根本没依赖任何带 ext-xxx 要求的包，config.platform.ext-xxx 就是摆设。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
容易被忽略的兼容性陷阱
平台模拟最危险的盲区在于：它不校验二进制文件或原生扩展是否真能在目标系统运行。例如 spatie/browsershot 会在安装时根据 PHP_OS_FAMILY 下载对应平台的 Puppeteer 二进制 —— 这个行为发生在 post-install-cmd 钩子里，config.platform 完全无法干预。
更现实的问题：
– 你在 macOS M1 上设 "platform": {"php": "8.1.10", "os": "linux"} → os 字段无效，Composer 会静默忽略
– 你靠 config.platform 让 grpc/grpc 被装上，但它实际需要编译 .so 文件 → 缺少 --with-grpc 配置或预编译产物，运行时仍会报 Class not found
真正跨平台可靠的方案永远是：在目标架构容器里跑 composer install，而不是靠 platform 配置“蒙混过关”。
