最稳的回滚方式是执行composer config -g repo.packagist composer https://packagist.org，需严格满足三点：键名必须为单数repo.packagist、中间composer为必需type值、URL须带https://且加-g；同时须检查并清除项目级repositories配置，清缓存后用composer require --no-install -vvv验证真实请求URL。
composer config -g repo.packagist 写不对就等于没换源
很多人执行了换源命令却没效果，根本原因是键名、类型、URL 三处任一写错，Composer 2.2+ 会静默回退到官方源，不报错也不提示。
必须严格满足：
-
repo.packagist（注意是单数repo，不是repos） - 值必须是 JSON 对象，含
"type": "composer"和"url"字段 -
url必须以https://开头、以/结尾，例如https://mirrors.aliyun.com/composer/
验证是否生效，只看这一条命令输出：composer config -g repo.packagist
如果返回空、null 或字符串 "https://packagist.org"，说明配置失败——常见于 Windows 下 %USERPROFILE%\AppData\Roaming\Composer\config.json 权限被系统锁定。
镜像源和 http-proxy 不能共存
一旦设置了 repo.packagist 镜像 URL，Composer 就直接连接该地址，完全绕过 http-proxy / https-proxy 配置。两者强行并存，反而可能引发 TLS 握手失败或 DNS 解析异常。
代理仅用于绕过防火墙，不是缓存机制：
-
http-proxy控制 HTTP 流量，https-proxy控制 HTTPS 流量，必须同时设置 - 代理地址必须用
http://协议前缀，即使目标是 HTTPS 站点 - 用户名密码含特殊字符（如
@、:）必须用rawurlencode()编码，例如pa@ss:word→pa%40ss%3Aword
想验证代理是否生效？运行 composer clear-cache && composer require monolog/monolog -vvv，在日志里搜 Downloading，确认 URL 前缀是你配的代理地址，而非 https://packagist.org。
CI/CD 中 vendor 缓存失效的三个硬伤
多阶段构建中，vendor 层缓存极易断裂，导致每次 CI 都重下包、重解压、重生成 autoload —— 构建时间从 30 秒拉长到 3 分钟以上。
最常踩的坑只有三个：
-
COPY . /app放在COPY composer.json composer.lock ./之前 —— 代码任意改动都会让缓存链彻底失效 - 在
COPY composer.json composer.lock ./和RUN composer install之间插入任何指令（比如RUN chmod或RUN mkdir）—— Docker 层缓存立即中断 - 没固定
COMPOSER_CACHE_DIR，又没启用 BuildKit 的--cache-from挂载 —— 每次都从零下载 ZIP 包
正确顺序唯一：先 COPY composer.json composer.lock ./，再 RUN composer install --no-dev --optimize-autoloader --classmap-authoritative --no-scripts。
阿里云镜像不是“最快”，而是“最稳”
测速脚本显示某镜像响应快 0.1s，不代表真实构建更快。真正卡住安装的是同步延迟和包可用性 —— 新发布的包在阿里云镜像里通常 1–3 分钟内就可装，清华源可能要等 15 分钟以上。
阿里云镜像的优势不在单次响应，而在三点：
- CDN 节点覆盖广，不同地域用户接入稳定
- 元数据与 dist 包同步机制健壮，极少出现
404或file not found - 对 Composer 2.2+ 的
repo.packagist配置兼容兜底强，少有静默降级
别依赖测速结果做决策；换源后务必跑一次 composer clear-cache，否则旧缓存会掩盖配置是否真正生效 —— 这是最容易被忽略、也最影响交付节奏的一环。
