需部署兼容 Composer 协议的私有仓库服务，推荐顺序为：① Satis（轻量开源，静态生成）；② Private Packagist（商业方案，企业级功能）；③ Toran Proxy（已停更，不建议新用）。
直接使用 Packagist.org 只能托管公开包，无法满足公司内部包的私有化需求。你需要搭建一个私有的 Composer 包仓库服务，而 Packagist.io 本身不提供私有仓库功能——它只是官方的公共索引平台。真正可行的做法是部署一个兼容 Composer 协议的私有仓库服务（如 Satis、Private Packagist 或 Toran Proxy），然后在公司内网或受控环境中运行，并配置团队的 composer.json 指向该私有源。
选择并部署私有仓库服务
主流方案有三种，按推荐顺序：
- Satis：轻量、开源、静态生成，适合中小团队。只需一台能跑 PHP 的服务器，用 Composer 安装后，通过 JSON 配置文件定义哪些 Git 仓库要打包、是否启用认证、生成 HTML 页面等。生成结果是纯静态文件，可直接用 Nginx/Apache 托管。
- Private Packagist：商业托管服务（也支持私有部署），提供 Web 界面、权限管理、Webhook 自动更新、审计日志、SAML 登录等企业级功能，适合中大型团队或对安全与运维有要求的场景。
- Toran Proxy（已停止维护）：不建议新项目使用；可作为历史参考，但存在安全与兼容性风险。
配置公司内部 Git 仓库与包规范
确保每个内部包都符合 Composer 标准：
- 根目录包含有效的
composer.json，其中name字段采用命名空间格式，如acme/utils或company/internal-api-client；避免使用无命名空间的名称（如utils），否则易与公共包冲突。 - 所有包代码托管在公司 Git 服务（如 GitLab、GitHub Enterprise、Bitbucket Server）上，且仓库为私有。Composer 会通过 SSH 或 HTTPS + Token 拉取源码，需提前配置好全局或项目级的认证方式（如
git config --global url."git@gitlab.internal:".insteadOf "https://gitlab.internal/"）。 - 打 Tag（如
v1.2.0）用于版本发布，Satis 默认只收录带语义化 Tag 的提交。
在项目中启用私有仓库
有两种常用方式，推荐后者：
-
全局配置（开发机）：运行
composer config -g repositories.acme '{"type":"composer","url":"https://packagist.acme.internal"}'，让本机所有项目默认信任该源。 -
项目级配置（推荐）：在项目
composer.json中添加：
"repositories": [{
"type": "composer",
"url": "https://packagist.acme.internal"
}],
并设置"minimum-stability": "stable"和"prefer-stable": true以避免意外拉取 dev 分支。 - 若私有仓库启用了 HTTP Basic 认证，还需在
auth.json（位于COMPOSER_HOME目录或项目根目录）中写入凭据：
{"http-basic": {"packagist.acme.internal": {"username": "api", "password": "xxx"}}}
自动化更新与权限控制
私有仓库不是“设一次就完事”，需建立可持续机制：
- 将 Satis 构建过程接入 CI（如 GitLab CI），当主包仓库有新 Tag 推送时，自动触发
satis build并同步到 Web 服务目录。 - 通过反向代理（如 Nginx）限制私有仓库的访问 IP 范围，或集成公司统一身份系统（如 LDAP/OAuth2）做登录鉴权（Private Packagist 原生支持）。
- 定期清理旧版本包（Satis 支持
archive配置生成 ZIP）、校验包完整性（启用require-dependencies和require-dev-dependencies）、禁用不安全的allow-plugins等，提升供应链安全性。
