composer install是唯一安全选项，因它严格按composer.lock的精确版本、哈希与校验和安装，确保多环境一致性；前提为composer.lock存在且未修改、vendor/为空、PHP版本及扩展满足lock中platform声明。
composer install 是唯一能填上这个黑洞的操作，不是镜像、不是复制 vendor/、更不是 composer update。
全量备份 Composer 镜像解决不了跨平台依赖同步问题——它根本不是为这事设计的。
为什么全量镜像对跨平台同步无效
镜像只缓存元数据（packages.json、provider-*.json），不托管实际包文件；而跨平台构建失败的根源，往往出在 dist 文件下载环节：dist.url 指向 GitHub Release、GitLab tag 或私有对象存储，这些地址不受镜像控制。
- 国内镜像同步延迟 5–30 分钟是常态，
composer.lock里记录的v1.2.3可能在阿里云镜像里还没出现，但官方源已有——你本地install成功，CI 却 fallback 到官方源后因网络策略失败 - Windows 和 Linux 下
vendor/的符号链接行为不同，直接拷贝会导致 autoloader 找不到类 - 镜像无法解决
auth.json权限缺失问题：同一composer.lock在 macOS 能装 GitLab 私有包，在 CI 中报401 Unauthorized，只是因为没挂载凭据
composer install 前必须验证的三件事
缺一不可，否则同步就是假同步：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer.lock必须存在且未被修改——运行git status -- composer.lock确认，不要信ls输出 -
vendor/目录必须为空或不存在——rm -rf vendor/比任何“清理命令”都可靠 - PHP 版本和扩展必须匹配
composer.lock顶部"platform"字段声明，例如"php": ">=8.1.0"；仅靠composer.json的require判断会漏掉ext-intl这类隐式依赖
CI/CD 中如何避免隐式 fallback 导致构建漂移
GitHub Actions、GitLab CI 默认不读取开发者本地的全局镜像配置，composer install 会静默回退到 https://packagist.org，而你的 composer.lock 是在阿里云镜像下生成的——元数据不一致时，Composer 会重新解析依赖图，版本可能升级或降级。
- 显式指定源：用
--repository-url=https://packagist.org强制对齐，而不是依赖全局 config - 禁用 fallback：加
--no-plugins --no-scripts防止插件干扰源选择逻辑 - 校验 lock 元数据时效性：在 CI 中
curl -s https://packagist.org/packages.json | jq -r '.lastModified'与本地 lock 里的packages.json时间戳比对，偏差超 60 秒就报警
真正容易被忽略的是：跨平台一致性不取决于你用了哪个镜像，而取决于所有环境是否用同一份未篡改的 composer.lock、是否清空 vendor/、是否满足 platform 声明——镜像只是加速手段，不是一致性保障。
