不走。只要composer.json定义了repositories数组，全局repo.packagist配置及关联的http-proxy/https-proxy即完全失效，元数据请求直连自定义url，不受代理控制。
composer config -g repo.packagist 配置后，自定义 repositories 还走代理吗？
不走。只要 composer.json 里定义了 repositories 数组（哪怕只有一项），全局的 repo.packagist 配置就完全失效——包括它背后依赖的 http-proxy 和 https-proxy 设置也一并被绕过。
这是因为 Composer 的源路由逻辑是两级隔离的：
- 元数据请求（
packages.json、provider-*.json）只发往repositories列表中声明的 URL，不经过代理配置 - 包文件下载（
.zip或.tar）是否走代理，取决于该包的dist.url是 HTTP 还是 HTTPS，且仅当没显式配置repositories时才受http-proxy/https-proxy控制
换句话说：你加了自定义 repositories，就等于手动接管了全部源发现流程，Composer 不再查全局镜像，也不再查代理设置。
type: "composer" 的自定义源，为什么有时卡在 provider-*.json 404？
不是代理问题，而是镜像同步延迟或路径拼接错误。
type: "composer" 源要求服务端提供完整的 Packagist v2 协议端点，包括：
-
/packages.json（根索引） -
/p/provider-laravel~10.0.json（按命名空间/版本前缀分片） -
/p2/laravel/framework/10.0.0.json（精确版本元数据）
常见失败原因：
- URL 末尾漏掉
/，导致拼成https://your-mirror.comprovider-laravel~10.0.json→ 404 - 内部镜像未启用 provider 分片同步，或滞后数小时，官方已有但镜像还没生成对应
provider-*.json - 用了
type: "packagist"（旧写法），新版本 Composer 2.x+ 直接忽略，静默 fallback 到 packagist.org
想让自定义仓库也走本地代理，该怎么配？
不能靠 http-proxy，得用环境变量或 cURL 全局配置。
Composer 本身不为 repositories 数组中的请求应用代理设置，但底层用的是 PHP 的 cURL 扩展。可行方案只有两个：
- 启动前设环境变量：
export HTTP_PROXY=http://127.0.0.1:7890和export HTTPS_PROXY=http://127.0.0.1:7890，然后运行composer install - 修改 PHP 的
curl.cainfo和系统级~/.curlrc，确保所有 cURL 请求（含 Composer 内部调用）都走同一代理
注意：composer config -g http-proxy 对自定义 repositories 完全无效，别白费力气配。
为什么禁用 packagist.org 后，私有包安装成功但 autoload 失败？
镜像源和自动加载是两件事。配置 {"packagist.org": false} 只影响「下载」，不影响「注册命名空间」。
典型表现：vendor/autoload.php 找不到类，但 composer show your/private-package 能列出已安装版本。
真正要检查的是：
- 私有包自己的
composer.json是否包含合法autoload块（如"psr-4": {"Your\Private\": "src/"}） - 该包是否被正确 require 进主项目，且 version 约束能匹配到已发布的 tag
- 执行
composer dump-autoload后再试，避免 autoloader 缓存残留
别指望改 repositories 就能自动解决 autoload —— 它只管“把代码拉下来”，不管“怎么加载”。
