结论：composer install 报“不支持该平台”，90% 是某个包在 require 里写了 Windows 没有的扩展（如 ext-posix），或本地 PHP 版本/扩展与 config.platform 声明不一致；config.platform 仅影响 composer update，对 install 无效，且必须置于 config 对象内、扩展名须严格匹配 php -m 输出。
直接说结论：composer install 报“不支持该平台”，90% 是某个包在 require 里写了 Windows 没有的扩展（比如 ext-posix），或你本地 PHP 版本/扩展和 config.platform 声明不一致——不是 Composer 故意卡你，是它在严格执行依赖约束。
为什么 Windows 上总报 ext-posix missing
这不是 Windows 的锅，是包作者把 ext-posix 写进了 require（常见于旧版 symfony/console、phpunit/phpunit 或某些 CLI 工具）。PHP 在 Windows 下确实不提供这个扩展，Composer 解析依赖时发现“要求存在但实际不存在”，就直接中断。
- 先定位谁加的：
composer show --tree | grep posix - 如果只是本地开发用（比如跑测试），把它从
require移到require-dev更合理 - 如果必须运行，代码里改硬调用为运行时判断：
if (function_exists('posix_getpid')) { ... } - 临时绕过可用：
composer install --ignore-platform-req=ext-posix，但别提交进composer.lock或 CI 脚本
config.platform 改了为啥没生效
config.platform 只影响 composer update 时的依赖解析，对 composer install 完全无效——它只照着 composer.lock 还原，根本不看你当前配置。
- 必须嵌套在
composer.json的"config": {}下，不能放顶层 - 扩展名必须带
ext-前缀，且大小写、连字符要和php -m输出完全一致（ext-xdebug✅，ext-xdebg❌） - 改完后必须执行
composer update --lock（或composer update），否则composer.lock仍是旧规则锁定的 - CI 流水线里执行
composer install前，确保composer.lock是用目标平台配置生成的
scripts 里的 shell 命令为什么跨平台就挂
scripts 字段是纯 shell 命令，Composer 不翻译、不兼容、不模拟。Windows cmd.exe 和 Linux bash 对语法、路径分隔符、工具链的支持完全不同。
- 别写
cp、rm -rf、ls、grep—— 这些在 Windows 原生命令行里根本不存在 - 路径拼接统一用正斜杠
/，PHP 7.4+ 会自动转义，别用DIRECTORY_SEPARATOR动态替换 - 需要删文件、复制资源？改用 PHP 原生函数：
RecursiveDirectoryIterator+FilesystemIterator或copy()+unlink() -
bin-compat=full只控制生成.bat/.sh包装器，不重写脚本逻辑；执行前务必在干净 Windows 环境下直接运行php bin/mytool，而不是mytool.bat
真正容易被忽略的点：跨平台问题从来不在 composer.json 配置里，而藏在你某一行代码中——比如 exec('which php')、sys_get_temp_dir() 返回带空格路径导致静默失败、或 __DIR__ . '/../../tmp' 这种硬拼路径。Composer 只管装得上，跑不跑得动，得你自己盯住每一处系统假设。
