应配置显式双源顺序+禁用隐式源+设置HTTP超时：先写内网镜像，再写packagist.org为type composer源，设"packagist.org": false，并在config中加"http": {"timeout": 5}或用COMPOSER_HTTP_TIMEOUT=5环境变量。
composer install 时镜像源失效，如何自动 fallback 到 packagist.org？
Composer 本身不支持“镜像不可用时自动回退”的内置机制。所谓“fallback”，本质是靠配置策略 + 网络健壮性控制实现的，不是开个开关就能生效。
最直接有效的做法是：**禁用镜像源配置，改用带条件判断的脚本逻辑，或利用 Composer 的 repositories 顺序优先级 + packagist.org 显式兜底**。
- Composer 解析
repositories是从上到下匹配的，只要把内网镜像放前面、官方源放后面，并设置"packagist.org": false（禁用隐式全局源），就能在镜像 404/502 时自然走到官方源 - 必须显式声明
packagist.org为 typecomposer源，否则即使写了"packagist.org": true，它也不会参与包查找（这是常见误解） - 内网镜像返回 404 时 Composer 会继续尝试下一个源；但若超时（如 DNS 不通、连接 hang 死），默认会卡住，需额外设
http://超时参数
{
"repositories": [
{
"type": "composer",
"url": "https://your-intranet-mirror.com"
},
{
"type": "composer",
"url": "https://packagist.org"
}
],
"packagist.org": false
}
为什么 composer config repo.packagist false 不起作用？
这条命令只是关闭了 Composer 默认隐式加载的 packagist.org，但它不会影响你手动写进 repositories 数组里的同名源——而且，如果你没手动加，那它就真没了，没有 fallback 可言。
-
composer config repo.packagist false和"packagist.org": false在composer.json中效果等价，都只关掉“默认源”，不关“显式声明的源” - 很多人误以为关掉默认源后 Composer 会自动用第二个源，其实不会：没显式写，就没有第二个源
- 执行该命令后，
composer show仍可能显示 packagist.org，是因为某些插件或全局配置干扰，应以项目级composer.json为准
如何让内网镜像失败时不卡住，快速切到本地或官方源？
关键不在 Composer 配置，而在 HTTP 客户端行为。Composer 底层用的是 cURL，超时由它控制，必须显式设短超时，否则一个挂掉的镜像能拖住整个 install 过程几十秒。
- 在
composer.json里加"config": {"github-protocols": ["https"], "http-basic": {}, "fxp-asset": {}}不解决问题，要加的是"http": {"timeout": 5} - 更稳妥的做法是：用
COMPOSER_HTTP_TIMEOUT=5环境变量启动，比写死在配置里更灵活，CI/CD 中可动态控制 - 如果内网镜像用的是自签名证书，还要配
"ssl": {"verify_peer": false}，否则会因证书错误直接中断，连 fallback 机会都没有
本地缓存能当 fallback 用吗？
不能直接当源用，但可以大幅降低对网络的依赖。Composer 的 cache-dir 存的是下载下来的 zip/tar 包和元数据，不是可服务的仓库。
- 已安装过的包，下次
composer install会优先从 cache 读取，跳过网络请求——但这只对已有 lock 文件且版本未变的情况有效 - 想离线装新包？得提前用
composer archive或第三方工具（如toran-proxy）把包导出为本地静态源，再配成type: artifact源 - 别指望
composer clear-cache后还能装——cache 是加速层，不是替代源
真正可靠的 fallback 组合是：显式双源配置 + 短 HTTP 超时 + 禁用隐式 packagist。其它都是补丁。网络不可靠时，别信自动，信顺序和超时。
