composer config -g repo.packagist 命令生效需同时满足四个硬性条件：键名为 repo.packagist（非复数）、显式指定 composer 类型、URL 为 HTTPS 且末尾带 /、必须加 -g 全局标志，缺一即静默回退至官方源。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是四个硬性条件缺一不可：repo.packagist（单数，不能拼成 repos.packagist）、composer（type 值必须显式写出）、https://mirrors.aliyun.com/composer/（URL 必须 HTTPS 且末尾带 /）、-g（全局标志）。漏一个就静默 fallback 到官方源，命令返回 0 却毫无作用。
常见失败组合：
-
composer config -g repo.packagist https://mirrors.aliyun.com/composer/→ 缺composertype，Composer 不识别，直接忽略 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer→ 少斜杠，请求路径变成/composerpackages.json，404 但不报错 -
composer config -g repo.packagist composer http://mirrors.aliyun.com/composer/→ HTTP 被 Composer 2.2+ 默认拒绝
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或报错，说明根本没生效。
CI/CD 或 Docker 构建中镜像源为何失效
全局配置 composer config -g 写入的是当前用户家目录下的 ~/.composer/config.json。CI 环境（如 GitHub Actions、GitLab CI）常以 root、www-data 或其他非登录用户身份执行命令，而你本地配的配置对它完全不可见。
更隐蔽的问题是缓存干扰：CI runner 可能复用旧缓存，或构建镜像时未清掉旧 vendor/ 和 composer.lock，导致 Composer 仍从 lock 文件里读取原始元数据地址，根本没触发新镜像。
推荐做法：
- 在 CI 脚本开头显式重置一次：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 强制清理：
composer clear-cache && rm -rf vendor/ composer.lock - 加
-vvv参数跑composer install，grep 日志确认出现mirrors.aliyun.com而非packagist.org - 或改用项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，提交composer.json到 Git，所有环境自动继承
阿里云镜像 vs 腾讯云镜像：选哪个更稳
阿里云镜像（https://mirrors.aliyun.com/composer/）同步及时、覆盖全，适合大多数场景；但若你部署在腾讯云华南节点或校园网环境，腾讯云镜像（https://mirrors.cloud.tencent.com/composer/）可能首包延迟更低、连接成功率更高。
关键差异点：
- ECS 内网用户务必用内网地址：
http://mirrors.tencentyun.com/composer/（HTTP，无 TLS 开销），公网 HTTPS 镜像反而增加延迟和流量成本 - 华为云镜像（
https://mirrors.huaweicloud.com/repository/php/）对私有包支持更好，企业级项目可优先考虑 - 别碰已下线源：
https://packagist.phpcomposer.com自 2022 年起 404，现在访问会跳转失败 - 多个镜像源并列写进
repositories数组 ≠ 自动 fallback —— Composer 只在前一个返回 404（包不存在）时才试下一个；超时、502、证书错误都会卡死，不会切换
生产部署中容易被忽略的三个关键动作
镜像源只是第一步，生产环境真正卡住的地方往往在后续环节：
- 必须始终用
--no-dev --no-scripts --no-autoloader安装依赖——框架的post-install-cmd可能在只读文件系统或并发部署时失败，中断整个流程 -
composer.lock必须存在且与composer.json兼容；Docker 构建中常因.dockerignore忽略了它，导致 COPY 后只剩composer.json，install实际退化为update，版本失控 - autoloader 优化不能合并在 install 命令里：先
composer install --no-autoloader，再单独composer dump-autoload -o——前者保证 vendor 目录干净落地，后者可控地生成 classmap，出错可重试
镜像源配得再稳，只要漏掉其中一项，composer install 就可能返回 0 却类找不到、缓存没清、权限报错，问题藏得深，排查费时间。
