Packagist不接受私有包，因其自2023年底关闭自动发现，仅手动索引公开仓库，要求仓库public、composer.json在main/master根目录、name为小写vendor/name且与账号一致，私有库提交必报Repository not found。
私有包不能发布到 Packagist，必须自建仓库或使用私有托管服务；直接在项目 composer.json 里配 "type": "vcs" 是开发阶段临时方案，不是发布流程。
为什么 Packagist 不接受私有包？
Packagist 自 2023 年底已关闭自动发现（auto-discovery），所有包都需手动提交 URL 并由其服务器远程读取根目录下的 composer.json。这个过程要求：
- 仓库必须是 public，否则网络不可达
-
composer.json必须位于默认分支（main或master）根目录 -
name字段必须为小写vendor/name格式，且vendor名需与 Packagist 账号一致 - 国内镜像（如阿里云、腾讯云）只同步 packagist.org 公开索引，不代理私有源
所以当你提交私有仓库 URL 后看到 Repository not found 或 Could not fetch package info，不是配置错，而是它根本拒绝处理。
企业级私有包发布的正确路径：Satis 或 Private Packagist
用 Satis 搭建静态私有仓库是主流选择，适合自运维团队。关键步骤如下：
- 安装 Satis：
composer create-project composer/satis:dev-main satis --stability=dev --no-interaction - 编写
satis.json，明确列出所有私有 VCS 地址："repositories": [{ "type": "vcs", "url": "https://git.example.com/company/auth-library.git" }] - 启用归档并跳过 dev 分支：
"archive": { "skip-dev": true, "format": "zip" }，否则 CI 拉取的 dist 包可能含测试代码 - 设置
homepage和prefix-url，确保生成的 dist 文件可被安全下载（如 CDN 域名） - 运行
php bin/satis build satis.json web/生成静态索引页和 dist 包
所有项目 composer.json 中的 repositories 只允许写入该 Satis 仓库地址（如 https://packages.internal/repo.json），禁止直连 Git 内网地址。
CI 构建时如何安全拉取私有包？
本地开发能装，CI 上失败，90% 出在环境隔离和认证上：
- CI 环境不能依赖开发者本地的
~/.composer/auth.json，必须通过环境变量注入 Token 或 SSH 密钥 - 强制指定仓库地址：
composer install --repository-url https://packages.internal/repo.json，避免被本地配置污染 - 若用 GitHub/GitLab 私仓 + HTTPS 认证，Token 必须带
repo（GitHub）或projects（Gitee）权限，且不能硬编码进composer.json - 禁用
"type": "vcs"直连——Git 服务器宕机时，CI 构建会全部中断；而 Satis 有缓存能力，可降级服务
真正上线的包，必须走统一仓库中转。所谓“发布”，不是把代码推到某个 Git 分支，而是让 Satis 抓取、验证、归档、索引、对外提供 JSON 接口——这才是可审计、可回滚、可灰度的发布。
容易被忽略的关键点
很多人以为打个 v1.2.0 tag 就算发布了，但实际漏掉三件事：
- Satis 配置里没设
"require-all": true或没显式"require": { "your-vendor/pkg": "*" }，新 tag 就不会被收录 - 私有包的
composer.json中version字段必须留空，靠 Git tag 解析；填死会导致 Satis 忽略该版本 - dist 包生成后，CDN 或 Web 服务器未开放
Content-Disposition: attachment头，某些 PHP 环境会因响应头不匹配拒绝安装
发布不是一次性的动作，而是索引、归档、分发、验证四个环节闭环。少一个，下游项目就可能在半夜部署时报 Could not find package。
