中小企业 composer 镜像配置核心是项目级声明：执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 写入 composer.json，确保 "packagist.org": false 在外层，清缓存、删 vendor 与 lock 后重装，并提交配置至 git。
直接用阿里云镜像 + 项目级配置，别碰全局配置——中小企业的 Composer 镜像配置核心就一条：所有项目必须自带可复现、可提交、不依赖本地环境的镜像声明。
为什么不能只配 composer config -g repo.packagist
中小企业常有 CI/CD 流水线（如 GitHub Actions）、多开发机、测试服务器、甚至宝塔面板部署，-g 写的是当前用户家目录下的 ~/.composer/config.json，但：
- GitHub Actions 默认用
runner用户，根本读不到你本机的全局配置 - 宝塔后台 PHP 进程通常以
www用户运行，而你终端是ubuntu或root，配置不互通 - 新同事 clone 项目后直接
composer install，没配全局镜像就卡死在Loading composer repositories
项目级配置怎么写才真正生效
进项目根目录（含 composer.json），执行这条命令：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动在 composer.json 顶层 repositories 字段里插入结构，且不会覆盖已有私有源。关键点：
- 必须确保
"packagist.org": false出现在repositories数组外层（不是某个仓库对象内部） - 私有源必须放在
repositories第一位，Composer 按顺序查找，同名包不会合并 - URL 末尾斜杠不能少：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出/composerpackages.json导致 404）
换源后还是卡住？清缓存和 lock 文件是硬要求
Composer 不会因为改了镜像就自动丢掉旧数据。即使你刚写入新配置，只要 composer.lock 里还记着 packagist.org 的 URL，它就会继续往那儿发请求。
必须按顺序执行：
composer clear-cacherm -rf vendor/ composer.lock-
composer install -vvv（观察日志中是否出现mirrors.aliyun.com）
如果日志里仍有 packagist.org，说明配置没写进 composer.json，或被其他 repositories 条目覆盖了。
别信“多加一个备用镜像”能自动 fallback
Composer 本身不支持镜像自动降级。你写两个 composer 类型源，它只会查第一个；第二个只有在第一个返回 404（不是超时、不是 TLS 错误）时才尝试——而国内镜像极少真返回 404。
真要防止单点失效，更实际的做法是：
- 只配一个主镜像（推荐阿里云）
- CI 脚本里加健康检查：
curl -sfI https://mirrors.aliyun.com/composer/packages.json | head -1，失败则切腾讯云 - 避免在
composer.json里硬编码多个公开镜像，容易让require行为不可预测
最常被忽略的一点：改完 composer.json 后，一定要提交到 Git —— 镜像配置不是开发环境的“个人习惯”，而是项目基础设施的一部分。
