镜像配置必须带 type=composer 和结尾斜杠，否则 HTTPS 代理失效；需禁用 packagist.org fallback 并配置可信 CA 证书，否则仍触发 TLS 审查。
镜像配置必须带 type 和结尾斜杠，否则 HTTPS 代理失效
很多团队配了镜像却仍走 packagist.org，根本原因是 Composer 在防火墙下对 URL 格式极其敏感——漏掉 type 或末尾 /，它会静默 fallback 到官方源，触发 TLS 审查规则。
-
type必须显式设为composer，不能省略；否则 Composer 2.0+ 直接忽略该仓库 -
url必须是 HTTPS 协议，且以/结尾，例如https://mirrors.aliyun.com/composer/（少斜杠会拼出/composerpackages.json导致 404） - 全局配置推荐命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级更稳妥：进项目根目录执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，自动写入composer.json的repositories字段
必须加 "packagist.org": false，否则防火墙照样拦截
只配镜像不关 fallback，等于把请求一半送进审查区。Composer 默认会在镜像失败后重试 packagist.org，而企业防火墙正是靠这个重试行为识别并阻断开发工具流量。
- 在
composer.json顶层加这一行："packagist.org": false（注意不是"packagist": false） - 这条配置必须和
repositories同级，且值为布尔false，不是字符串"false" - 验证是否生效：运行
composer install -vvv，日志里不应出现任何packagist.org域名请求 - 如果已有私有源在
repositories数组里，别手动覆盖整个字段，用composer config命令追加，避免误删
HTTPS 被拦截？先验证是否 TLS 内容审查，再配可信 CA
现象是 curl -vI https://mirrors.aliyun.com/composer/packages.json 报 certificate verify failed，但浏览器能打开——说明防火墙在做 TLS 解密，不是网络不通。
- 导出公司根证书（通常从浏览器导出“本地 CA”证书），保存为 PEM 格式（无 BOM、纯文本）
- 执行
composer config -g cafile /path/to/company-ca.crt（Linux/macOS 用正斜杠，Windows 用双反斜杠如C:\certs\company-ca.crt） - 临时伪装 UA 避免被规则库标记：
export COMPOSER_USER_AGENT="Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36"，再跑composer update -vvv - 绝对不要设
secure-http false或COMPOSER_CAFILE=/dev/null，这等于主动关闭证书校验，供应链风险极高
换源后仍卡在 “Resolving dependencies”？和镜像无关
镜像只加速元数据下载，不解决依赖解析慢的问题。如果你发现卡在 Resolving dependencies 几十秒以上，基本可以确定是约束太松或环境问题。
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试遍历大量不兼容组合 -
require-dev里塞了太多未锁定版本的工具链（如phpunit:^9.0），会显著拖慢解析 - PHP 版本低于 Composer 2.5+ 推荐的最低要求（PHP 7.4+），部分优化算法不可用
- 换任何镜像都无效，得收紧约束、拆分 dev 包、用
composer.lock锁定版本
ping mirrors.aliyun.com 和 curl -I https://mirrors.aliyun.com/composer/packages.json 看底层通不通，比反复调 Composer 参数更省时间。镜像不是魔法，它只是代理——DNS 解析慢、CA 不信任、URL 格式错，都会让它失效。 
