Composer只负责安装，不保证运行时兼容；ext-posix缺失因依赖声明硬要求，可用--ignore-platform-req=ext-posix临时绕过，但需改代码适配或移至require-dev。
Composer 本身不解决跨平台运行时兼容问题，它只管“装得上”，不管“跑得动”。真正决定能否在 Windows、Linux、macOS 上一致工作的，是你的 composer.json 配置、依赖包自身行为，以及你有没有在代码里偷偷写死 /usr/bin/env php 或 exec('ls') 这类系统假设。
为什么 composer install 在 Windows 上报 “ext-posix missing”？
这是最常被误读的错误。它不是 Composer 故意为难你，而是因为某个包（比如 symfony/console 的旧版或某些 CLI 工具）在 require 中声明了 "ext-posix": "*" —— 而 ext-posix 在 Windows 上默认不可用。
- 别急着删掉这个 require，先查清楚是谁加的：运行
composer show --tree | grep posix - 如果只是开发时用（比如本地跑测试），把它挪到
require-dev里更合理 - 如果必须用，改用运行时判断代替扩展硬依赖：
if (function_exists('posix_getpid')) { ... } - 临时绕过？可以用
composer install --ignore-platform-req=ext-posix，但别提交到 CI
platform 配置到底骗谁？
"platform" 只骗 Composer 自己，不骗 PHP 解释器。它让 composer update 按你写的 PHP 版本和扩展去选包，但不会让 PHP 7.4 突然支持 match 表达式。
- 适用场景：你在 macOS 上开发，但目标部署环境是 PHP 8.2 + Alpine Linux，想提前生成适配的
vendor/ - 危险操作：写了
"platform": {"php": "8.2.0"}就以为能在 PHP 7.4 上跑 Laravel 11 —— 不行，syntax error, unexpected token "match"会立刻打脸 - CI 中建议搭配
php -v校验：先确认当前 shell 的php -v输出匹配预期，再跑composer install
bin-compat=full 为什么没用？
设了 "bin-compat": "full" 却发现 vendor/bin/mytool.bat 还是启动失败，大概率是因为脚本本身调用了 POSIX-only 命令，或者路径写死了 /tmp。
-
bin-compat=full只控制包装器生成（.bat / .sh），不重写脚本逻辑 - 执行前检查：在干净 Windows 环境（无 WSL、无 Git Bash）下直接运行
php bin/mytool，不是mytool.bat - 脚本里禁用
shell_exec('grep')、exec('rm -rf')，改用file_get_contents()+str_contains()或RecursiveDirectoryIterator - 路径处理必须用
realpath()和dirname(__DIR__)，别拼__DIR__ . '/../../tmp'
跨平台真正的分水岭不在 Composer 配置，而在于你有没有在任何一行代码里，把操作系统当成了理所当然的存在——哪怕只是 sys_get_temp_dir() 返回带空格的路径，都可能让某个 exec() 调用静默失败。
