最干净的方式是在CI/CD命令中直接使用--repository-url参数，如composer update --repository-url=https://mirrors.cloud.tencent.com/composer/，避免全局配置污染，同时需清缓存、删lock与vendor并验证HTTP请求是否命中镜像域名。

CI/CD里用--repository-url最干净

腾讯云 CODING 流水线里，别碰全局 config，直接在命令里加 --repository-url 参数。它会完全忽略项目级和用户级配置，只连你指定的镜像地址，避免环境污染和配置冲突。

• composer update --repository-url=https://mirrors.cloud.tencent.com/composer/ 是标准写法，-r 参数在 CODING 里不推荐——它不支持 create-project，且部分 Composer 版本对 -r 解析不稳定
• 必须用 HTTPS + 末尾 /，否则 Invalid repository type 错误会在流水线里静默失败，日志只显示 “Could not fetch”，很难定位
• 搭配 -vvv 可确认真实请求地址：composer update -vvv --repository-url=... 日志里会出现 GET https://mirrors.cloud.tencent.com/composer/p2/...

换源后必须清缓存和 lock 文件

流水线是干净容器，但 Composer 缓存和 composer.lock 仍可能残留旧源信息。尤其当上一次构建用了 packagist.org，lock 文件里的 dist.url 还是指向 GitHub，导致 zip 下载卡在 codeload.github.com。

腾讯云跨账号资源迁移

腾讯云跨账号资源迁移工具，支持将账号A的VPC、CLB、NAT、CVM、安全组等资源迁移至账号B，通过CCN云联网实现跨账号网络互通，提供自动扫描、配置生成、Terraform部署功能。

下载

• 执行 composer clear-cache 清掉本地元数据缓存，防止读取过期的 p2 索引
• 删掉 composer.lock 和 vendor/ 目录再重装，否则 --repository-url 只影响元数据解析，不影响已记录的 dist 下载地址
• CODING 构建脚本里建议写成：rm -f composer.lock vendor/ && composer install --no-interaction --repository-url=https://mirrors.cloud.tencent.com/composer/

验证是否真走腾讯云镜像

别只看命令没报错，得确认实际 HTTP 请求发到了哪儿。CODING 流水线日志里搜关键词比看 exit code 更可靠。

• 运行 composer show laravel/framework --no-ansi | head -n 5，输出里若含 mirrors.cloud.tencent.com 就说明生效
• 更直接：加 -vvv 后 grep GET 行，比如 composer update -vvv ... 2>&1 | grep "GET https"，应看到镜像域名而非 packagist.org
• 如果看到 Repo packagist.org is default，说明 repo.packagist 键名写错了（比如多写了 s），或 URL 缺斜杠，配置根本没加载

项目里有私有仓库时怎么共存

很多 CODING 项目同时用腾讯云镜像 + 私有 Git 包，不能简单删掉 repositories 段，否则私有包拉不到。

• 别用 composer config repo.packagist 覆盖整个 repositories 字段——它会清掉你原有的私有源
• 手动编辑 composer.json，在 "repositories" 数组里加一条：{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}
• 确保这条在数组开头或结尾，且 "packagist": false 不要设为 false，否则镜像会被禁用；留空或删掉该字段即可

腾讯云镜像不托管 ZIP 包，只加速元数据层。CODING 流水线里真正拖慢构建的，往往是 GitHub 下载环节——这点容易被忽略，以为配了镜像就万事大吉。