Composer如何使用Private Packagist_Composer Private Packagist使用策略

Private Packagist 配置实战：避开那些“静默失败”的坑

Token配置：全局命令是唯一正解，别在文件里手写

只修改项目里的 composer.json，却忘了配认证令牌？那结果必然是失败。Private Packagist 不接受匿名访问，而且它也不认你在项目目录下手动创建的 auth.json 文件——尤其是在 CI/CD 流水线中，这种错配非常普遍。

正确的操作路径其实很清晰：

• 第一步，去 Private Packagist 后台的「API Tokens」页面，生成一个 read 或 read-write 权限的令牌。
• 第二步，打开终端，执行这条关键命令：composer config -g http-basic.repo.packagist.com ""。注意，密码字段必须是一个空字符串。
• 这个操作会将凭证写入全局的 $COMPOSER_HOME/auth.json 文件。此后，Composer 的每次请求都会自动带上格式完全正确的 Authorization: Basic 头。

对于 CI 环境，更可控的方式是使用 COMPOSER_AUTH 环境变量。其值应该设置为：{"http-basic":{"repo.packagist.com":{"username":"TOKEN","password":""}}}。这比在容器里挂载配置文件要可靠得多。

源声明：必须“关公网，开私源”，顺序不能乱

这里有个常见的误解：以为在 repositories 里添加了私有源，Composer 就会乖乖只用它。实际上，默认情况下 Composer 仍然会回退到 packagist.org 去查找包。这会导致一系列诡异问题：私有包被跳过、同名包意外地从公网拉取，甚至因为权限冲突直接报 401 错误。

所以，必须在项目的 composer.json 文件中完成两件缺一不可的事：

• 使用 "packagist": false 彻底关闭默认的公共包仓库。
• 使用 "private-packagist": { "type": "composer", "url": "https://repo.packagist.com/your-org/" } 明确声明你的私有源地址。注意，URL 末尾的斜杠 / 必不可少。

顺序是关键：私有源的声明必须放在 "packagist": false 之后。另外，type 字段务必写成 "composer"，写成 "vcs" 或者留空，都会直接导致元数据解析失败。

包找不到？先别急着怀疑配置，检查后台状态和大小写

遇到 package not found 错误，先别一股脑去折腾令牌和源地址。Private Packagist 对包的可见性控制极为严格，连接了代码仓库并不等于包就能被安装。常见的卡点有几个：

• 包未在后台“启用”：在 Private Packagist 后台的「Packages」列表里，每个包都有一个启用开关。如果它是灰色的，那么 Composer 根本无法发现这个包。
• 包名大小写不匹配：acme/MyLib 和 acme/mylib 会被视为两个完全不同的包，务必精确匹配。
• 私有 Git 仓库同步：对于 git@github.com:acme/private-lib.git 这类仓库，需要在后台完成同步操作，并务必勾选「Include in composer repository」选项。
• 缓存问题：执行一下 composer clear-cache 再试。有时候旧的 packages.json 缓存里还记录着之前 404 的结果。

所以，下次再遇到包找不到，第一反应应该是登录 Private Packagist 后台，确认目标包的状态显示为 “Enabled”，并且有可见的版本号列表。

HTTPS强制策略：内网HTTP部署的“死局”与破局

Composer 3.0 及以上版本有一个重要变化：默认拒绝所有非 HTTPS 协议的仓库源。如果你在内网使用 HTTP 协议部署了 Private Packagist 实例（例如 http://packagist.internal），那么即使所有配置都正确，Composer 也会静默失败或者直接报 Connection refused。

面对这个情况，解决方案只有两个，没有中间选项：

• 为内网实例配置合法的 TLS 证书。这是推荐的做法，一劳永逸，也能避免未来其他工具链出现兼容性问题。
• 将 Composer 版本降级到 2.x。这不推荐，意味着你将放弃安全更新和新特性。

需要警惕的是，以前常用的 --no-secure-http 参数在新版中已被移除，任何试图通过修改源码来绕过验证的做法，都属于会给后期运维埋下大坑的危险操作。