根本原因是Composer校验运行环境（PHP版本、扩展、位数等）与composer.lock中平台约束不一致；可用--ignore-platform-reqs跳过全部检查，或按需指定--ignore-platform-req=php-64bit等参数，但无法解决vendor/bin二进制文件的CPU或libc兼容性问题。
composer install 在跨平台同步依赖时失败，根本原因不是锁文件本身有问题，而是 Composer 默认校验当前运行环境（PHP 版本、扩展、php-64bit 等）是否与 composer.lock 中记录的平台约束一致。macOS 上装为 Linux 构建的包、Windows 上装 ARM64 依赖，都会触发 Your lock file does not contain a compatible set of packages。
用 --ignore-platform-reqs 跳过全部平台检查
这是最直接的绕过方式，适合本地快速验证或 CI 中临时构建：
-
composer install --ignore-platform-reqs会忽略php、ext-xdebug、php-64bit、ext-sodium等所有平台相关约束 - 它不修改
composer.lock，也不影响后续composer update的行为 - ⚠️ 注意：这只是让安装“通过”，不代表运行时能用——比如
spatie/browsershot调用的 Puppeteer 二进制仍可能报Bad CPU type in executable - 不要在生产部署脚本中硬编码该参数，容易掩盖真实兼容风险
按需忽略特定架构项（更安全）
比起全量跳过，只绕过真正阻碍安装的项，保留关键检查（如 PHP 版本、必需扩展），更利于暴露潜在问题：
- 忽略位数约束：
composer install --ignore-platform-req=php-64bit或--ignore-platform-req=php-32bit - 忽略某个扩展：
--ignore-platform-req=ext-xdebug（注意不是--ignore-platform-reqs=ext-xdebug，后者语法错误） - 可叠加多个：
composer install --ignore-platform-req=php-64bit --ignore-platform-req=ext-sodium -
php-64bit和php-32bit是 Composer 内部识别的平台标识，不是 PHP 自身常量，不能替换成PHP_INT_SIZE之类
vendor/bin 下命令仍报错？那是二进制不兼容，不是 Composer 的锅
即使 composer install 成功了，vendor/bin/phpunit 或 vendor/bin/pest 启动失败，常见错误如：
-
Bad CPU type in executable（macOS M1/M2 上运行 x86_64 二进制） -
cannot execute binary file: Exec format error（Linux x86_64 宿主机运行 ARM64 二进制） - 这是因为这些可执行文件是预编译的，绑定目标平台（如 Alpine musl、glibc 版本、CPU 指令集），
--ignore-platform-reqs对它们完全无效 - 解法只有两个：换用纯 PHP 实现的替代品（如用
phpunit/phpunit的 PHAR 入口而非 vendor/bin 下 shell wrapper），或改用"bin-compat": "full"并确保包提供bin/目录下的 PHP 脚本而非二进制
跨平台同步依赖真正的难点不在安装阶段，而在运行时——Composer 只管 PHP 包的 autoload 和依赖解析，不管二进制、扩展、系统库。哪怕锁文件里写着 "platform": {"php": "8.2.0", "php-64bit": true}，也拦不住一个打包时就绑死 musl libc 的可执行文件在 glibc 环境下直接崩溃。
