Composer CLI 本身就是 API 客户端，官方不提供稳定公开的 HTTP API；所谓“API 调用”实为底层复用 Packagist 的 /packages/{vendor}/{package}.json 等内部接口，需严格遵循 User-Agent、大小写敏感、语义化 tag 等约定，且结构随版本变更；稳定自动化应优先使用 composer show --format=json 等 CLI 命令。
Composer CLI 本身就是 API 客户端，没有独立的 HTTP API
Composer 官方不提供对外的 REST 或 GraphQL 接口。所谓“通过 API 管理包”，实际是指 composer 命令行工具如何与 Packagist（或私有仓库）通信——它底层走的是 HTTPS + JSON over HTTP，但这个协议未公开文档、不承诺稳定性，也不建议直接调用。
你看到的 packagist.org 网站接口（比如 /packages/{vendor}/{package}）是前端渲染用的，返回 HTML；真正的元数据交互走的是 /packages.json、/p/{vendor}/{package}.json 这类路径，但这些属于 Composer 的内部约定，随时可能变更。
- 直接请求
https://packagist.org/p/vendor/package.json可能返回 404 或 403，因为 Packagist 对未带User-Agent: Composer/2.x的请求限流或拦截 - 响应体结构依赖 Composer 版本：v1 返回扁平
versions数组，v2 引入了metadata+files分离设计 - 认证私有包时，Composer 会读取
auth.json并在请求头中注入Authorization: Bearer xxx，手动模拟需同步处理 token 刷新逻辑
想自动化管理包？优先用 composer 命令 + --no-interaction
真正稳定、可脚本化的“API”就是 CLI 本身。Composer 提供了足够细粒度的命令来查、装、卸、更新，配合 JSON 输出和退出码，适合集成进 CI/CD 或运维工具。
-
composer show --format=json vendor/package获取包信息（含版本、依赖、autoload 映射） -
composer require --dry-run --no-update vendor/package:^2.0预检是否冲突，不写入composer.json -
composer update --with-dependencies --no-scripts vendor/package升级指定包及其直系依赖，跳过脚本执行 - 所有命令加
--no-interaction避免卡在 prompt，加-v或--debug查看真实 HTTP 请求地址和响应头
注意：composer install 默认读 composer.lock，若想强制重解析依赖图，必须加 --no-cache 并确保 composer.json 已更新——否则命令看似成功，实际没生效。
自建仓库时，composer repo 命令不存，得靠 composer.json 配置驱动
Composer 没有 composer repo add 这种命令。添加私有仓库，唯一方式是在项目或全局 composer.json 中声明 repositories 字段：
{
"repositories": [
{
"type": "composer",
"url": "https://your.repo.example.com"
}
]
}
关键细节：
-
type必须是composer、package或path，不能填git或http—— 那些是package类型下的子配置 - 私有仓库若用 Basic Auth，URL 要写成
https://user:pass@your.repo.example.com，且需设置"options": {"http": {"header": ["Authorization: Basic ..."]}}才能绕过 CLI 的 auth.json 机制 - 本地
path类型仓库不走 HTTP，但要求目标目录含合法composer.json，且composer update时会硬链接而非复制文件，改源码会实时反映到 vendor
调试网络行为：用 COMPOSER_HTTP_PROXY 和 --debug 看清底层请求
Composer 底层用的是 PHP 的 ext-curl，所有请求都受环境变量和配置控制。排查超时、证书错误、401 等问题，别猜，直接让 Composer 吐出原始请求。
- 设
export COMPOSER_HTTP_PROXY=http://127.0.0.1:8888，再用 Charles/Fiddler 抓包，能看到完整 URL、Header、Body -
composer diagnose -v会检查 cafile、proxy、disable-tls 等配置是否生效 - 常见坑：
openssl.cafile在 php.ini 中配置后，Composer 不一定读取——它优先查composer config cafile或环境变量COMPOSER_CAFILE - 公司内网若用自签名证书，不要改系统 cert store，直接运行
composer config -g cafile /path/to/corp.crt
真正难的不是发请求，而是理解 Composer 如何把一个 require 解析成几十次 HTTP GET：先查 packages.json 索引，再逐个取 p/vendor/name.json，最后下载 .zip 或 git clone。中间任何一环 4xx/5xx，它都可能静默 fallback 或报错模糊。
