为旧版PHP项目平滑迁移至新版Composer镜像的指南-composer-PHP中文网

换镜像不能解决composer.lock中已记录的原始源地址拉取问题，因install严格按lock文件执行；必须先执行composer update生成新lock文件，才能使新镜像生效。

为旧版php项目平滑迁移至新版composer镜像的指南

直接换镜像不会自动解决依赖问题，composer install 仍会按 composer.lock 中记录的原始源地址拉取——换镜像只对新安装或 update 生效，且必须同步更新私有源认证与平台约束。

旧项目若已存在 composer.lock，Composer 会严格按其中记录的 dist URL 和 source URL 拉包，完全忽略当前配置的镜像源。常见现象包括：

根本原因：镜像只影响「解析阶段」（update 时找包）和「下载阶段」（新包走镜像），不影响「还原阶段」（install 时照 lock 执行）。

在改镜像或跑命令前，先检查：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

composer.lock 是否存在且未被 .gitignore 屏蔽（ls -la | grep composer.lock）
lock 文件顶部 "platform" 字段声明的 PHP 版本（如 "php": ">=8.1.0"）是否匹配当前环境（php -v）
lock 中所有包的 "source" 类型（vcs / package / dist）是否仍在目标镜像覆盖范围内；特别注意 "type": "vcs" 的包，镜像不代理 Git 操作

不是简单执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就完事：

先清理旧锁文件影响：运行 composer update --dry-run，确认无报错后再执行 composer update 生成新 composer.lock —— 此时才真正走新镜像

若项目含私有包，需额外在 composer.json 中显式声明仓库，并确保认证就绪：

{
  "repositories": [
    {
      "type": "composer",
      "url": "https://your-private-mirror.example.com"
    }
  ]
}

本地换镜像成功 ≠ 线上部署成功。必须同步检查：

CI 脚本中是否硬编码了 composer install，而没加 --no-interaction 和 --prefer-dist（否则可能卡在交互式提示）
Dockerfile 中是否仍用 FROM php:7.4，但新 lock 要求 php >=8.1，导致 install 直接跳过关键包
团队成员是否各自运行了 composer self-update？Composer 2 对镜像源解析更严格，1.x 下能绕过的权限错误在 2.x 会直接中断

最常被忽略的是：换镜像后没重跑 composer update，却把旧 composer.lock 提交到 Git，结果所有人 install 时还在连原始源——镜像等于白配。