“不支持该平台”是composer在拦截php版本或扩展（如ext-posix）与require声明不匹配，而非拒绝操作系统；它校验require中声明的php、扩展等是否真实可用，且config.platform仅影响update，install只认composer.lock。
composer install 报 “不支持该平台” 是什么在拦你
它不是在拒绝你的操作系统，而是在校验 composer.json 里 require 声明的 PHP 版本、扩展（如 ext-posix）、ICU 或 lib-* 是否真实可用。Windows 上常见报 ext-posix 缺失，不是 Windows 有问题，是某个包（比如旧版 symfony/console）把它写进了 require —— PHP 在 Windows 下确实不提供这个扩展。
关键判断点：
- 运行
composer show --tree | grep posix，看谁引入了ext-posix - 运行
php -m，确认本地实际加载的扩展名（必须带ext-前缀，大小写严格匹配） - 检查
composer.json的config.platform是否存在、是否放在"config": {}内、是否拼写正确
config.platform 改了但没生效？它只管 update，不管 install
config.platform 是 Composer 的“依赖解析模拟器”，只在 composer update 时起作用：告诉 Composer “假设我有 PHP 8.2 和 ext-redis”，从而选出兼容的包版本。但它对 composer install 完全无效——后者只照着 composer.lock 里的记录还原，根本不看你当前 config.platform 设了啥。
所以改完 config.platform 后必须执行：
-
composer update --lock（推荐，只更新 lock 文件，不改 vendor） - 或
composer update（会重装 vendor，慎用） - CI 流水线里跑
composer install前，确保composer.lock是用目标平台配置生成的
Windows 上死卡 ext-posix？别硬扛，分场景处理
如果只是本地开发或跑测试，ext-posix 不是刚需。优先从 require 移到 require-dev，避免污染生产环境约束。
如果代码里真用了 posix_getpid() 这类函数，改成运行时判断：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
if (function_exists('posix_getpid')) {
$pid = posix_getpid();
} else {
$pid = getmypid();
}
临时绕过安装限制可用：
-
composer install --ignore-platform-req=ext-posix（仅跳过 posix，其他仍校验） -
composer install --ignore-platform-reqs（全关，风险最高，别上 CI）
注意：--ignore-platform-reqs 不等于能跑，只是让安装通过；PHP 7.4 强装 Laravel 11，composer install 成功，php artisan 第一行就 Fatal error: Uncaught ParseError: syntax error, unexpected token "="。
跨平台 scripts 失效？别写 shell 命令，改用 PHP
scripts 字段是纯 shell，Composer 不翻译、不兼容、不模拟。Windows 的 cmd.exe 和 Linux 的 bash 对 cp、rm -rf、grep、路径分隔符（\ vs /）完全不认。
安全做法：
- 路径统一用正斜杠
/，PHP 7.4+ 会自动转义 - 删文件、复制资源，改用 PHP 原生函数：
RecursiveDirectoryIterator+FilesystemIterator，或copy()+unlink() - 需要生成包装脚本时，
bin-compat=full只控制生成.bat/.sh，不重写逻辑；执行前务必在干净 Windows 环境下直接运行php bin/mytool，而非mytool.bat
真正容易被忽略的是：哪怕你把 config.platform 和 scripts 都调对了，只要 composer.lock 是在 macOS 上生成的、又拿去 Windows CI 里 install，而锁文件里记录了某扩展的 x86_64 预编译二进制（比如某些 ext-swoole 版本），照样失败——因为 M1/M2 或 Windows ARM 机器根本跑不动。
