ext-posix在windows报错是因依赖包强制要求该扩展，而windows不支持；应通过composer show定位来源，移至require-dev或运行时检测function_exists，精确忽略用--ignore-platform-req=ext-posix，config.platform需正确配置并执行composer update --lock。
为什么 ext-posix 会在 Windows 上报错
不是 Composer 故意为难你，而是某个包（比如旧版 symfony/console、phpunit/phpunit）在 require 里写了 "ext-posix": "*"。Windows 没有 ext-posix，PHP 加载不了，Composer 就直接拒绝解析依赖树。
先定位是谁加的：composer show --tree | grep posix。如果只是本地开发或跑测试用，把它从 require 移到 require-dev 更合理；如果必须运行，代码里得加运行时判断：if (function_exists('posix_getpid')) { ... }，不能无条件调用。
如何安全地跳过 ext-* 检查
--ignore-platform-reqs 是最粗暴的解法，但会同时跳过 PHP 版本、所有扩展、甚至 lib-* 检查，CI 环境里千万别提交进 composer.lock。
更推荐精确忽略：composer install --ignore-platform-req=ext-posix。也可以多写几个：composer install --ignore-platform-req=ext-posix --ignore-platform-req=ext-pcntl。这样既绕过构建障碍，又保留对 PHP 版本等关键项的校验。
注意：--ignore-platform-req=ext 是批量忽略所有扩展，但无法区分哪些是真需要、哪些只是开发工具依赖——容易掩盖真实兼容性问题。
config.platform 怎么写才不白配
config.platform 只在 composer update 时生效，对 composer install 完全没用——除非你先用目标平台配置生成新的 composer.lock。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
必须嵌套在 composer.json 的 "config": {} 下，不能放顶层；扩展名必须带 ext- 前缀，且大小写、连字符要和 php -m 输出完全一致（ext-xdebug ✅，ext-xdebg ❌）；值可以是 true 或任意非空字符串，Composer 只检查“是否存在”，不校验版本。
改完后必须执行 composer update --lock，否则 composer.lock 仍按旧规则锁定，白改。
运行时检测比安装时更重要
就算你用 --ignore-platform-req 装上了包，如果代码里无条件调用了 posix_getpid() 或 pcntl_fork()，运行时照样 fatal error。
真正该做的是：把硬依赖改成运行时探测 + 降级逻辑。比如用 \Composer\InstalledVersions::isInstalled('vendor/package') 判断功能模块是否可用，再配合 function_exists() 检查扩展；不要让 composer install 成为唯一防线。
最容易被忽略的点是：某些包（如 symfony/polyfill）加载即注册函数别名，看似没 use，实则已被自动加载机制悄悄触发——删包前务必确认是否产生副作用。
