composer config -g repo.packagist 基本无效，因键名、type值、url格式三处硬性条件未同时满足：键名必须为repo.packagist（非repos）、type必须显式写composer、url须https且末尾带/，任一出错即静默回退官方源。
直接配 composer config -g repo.packagist 基本无效——90% 的失败不是因为网络，而是键名、type、URL 格式三处硬性条件全没满足。
composer config -g repo.packagist 为什么总不生效
Composer 2.x 对配置错误完全静默：写错就 fallback 到官方源，不报错也不提示。常见失效组合：
-
repo.packagist写成repos.packagist（多一个s） - 漏掉必需的
"type": "composer"字段，只写了 URL - URL 用
http://或结尾没加/，例如https://mirrors.aliyun.com/composer❌ - Windows 用户手动改了
C:\Users\用户名\AppData\Roaming\Composer\config.json，但 JSON 格式错或权限不足
验证是否成功，只看这一条命令输出：composer config -g repo.packagist。必须返回完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；返回 null、Key not found 或纯字符串（如 "https://..."），说明没写进去。
Docker 容器里该用项目级配置，别碰全局
CI/CD、宝塔、Docker 容器通常以 www 或 runner 用户运行，根本读不到你本地用户的全局配置。项目级配置写进 composer.json，Git 可追踪、所有人行为一致。
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不带-g） - 该命令会自动识别已有
repositories结构：是对象就写入"packagist"键，是数组就追加新项，不破坏私有源 - 千万别手动写
"packagist": false——这会导致php、ext-json等基础约束校验失败 - 改完立刻跑：
composer update --lock，确保composer.lock记录的是镜像源地址，而非官方源
Docker 构建时挂载缓存 + DNS 优化才是真提速
镜像源只加速元数据拉取和 ZIP 包下载，不解决依赖解析卡顿（比如卡在 Resolving dependencies）。容器内 Composer 慢，大概率是以下三件事没做：
- 挂载 Composer 缓存目录：
-v ~/.composer-cache:/root/.composer/cache（Linux/macOS）或-v %USERPROFILE%\AppData\Roaming\Composer\Cache:/root/.composer/cache（Windows） - DNS 配置必须显式指定，避免容器默认 DNS 解析慢：
--dns 114.114.114.114或在/etc/docker/daemon.json中全局加"dns": ["114.114.114.114"] - 避免频繁挂载整个
vendor目录——它会覆盖容器内已安装的依赖，导致重复安装；改用命名卷或只挂载composer.json/composer.lock
换源后仍卡在依赖解析阶段？检查 composer.json 里 PHP 版本约束是否太宽（如 "php": "^7.4 || ^8.0 || ^8.1"），或是否存在大量未锁定的 dev- 分支依赖（如 "monolog/monolog": "dev-main"）——这些和镜像源无关，得靠缩小约束范围或锁定分支来解决。
