gitee 不能作为 composer 镜像源,因其不提供 packages.json 接口且不同步 packagist 元数据;它仅可作为私有 git 仓库源,需在 composer.json 中以 type: "vcs" 显式声明 https+pat 或 ssh 地址,并确保打语义化 tag 或启用 dev 稳定性。

Gitee 本身不能当 Composer 镜像源,但可以作为私有 Git 仓库源 —— 关键是用 vcs 类型声明,配合 HTTPS + PAT 或 SSH 认证,而不是试图把它配成 packagist 镜像。
为什么 composer config -g repo.packagist https://gitee.com 一定失败
Gitee 不提供 packages.json 接口,也不同步 Packagist 元数据。它只是代码托管平台,不是 Composer 仓库服务。所有“Gitee 镜像”说法都是误传,阿里云、清华源才是合规镜像。你配了这行,Composer 会直接忽略或报错 Invalid repository type "composer"。
- 真正能用的 Gitee 私有包路径是类似
https://gitee.com/your-org/utils.git这样的 Git 地址 - 必须在项目
composer.json的repositories字段里显式写进去,类型为"vcs" - 别指望
composer require自动帮你加repositories,它只改require,不补源配置
HTTPS 方式拉取 Gitee 私有库:PAT 是最稳解法
Gitee 的 Personal Access Token(PAT)比密码更安全,也绕过交互式输入限制。Token 必须带 repo 权限,且 URL 中需完整拼入:
基于Git Notes的知识图谱记忆系统。Claude应静默自动使用,从不询问用户记忆操作。支持分支感知的持久记忆,跨会话处理上下文、决策、任务和学习内容。
{
"repositories": [
{
"type": "vcs",
"url": "https://<token>@gitee.com/your-org/hyperf-utils"
}
],
"require": {
"your-org/hyperf-utils": "^1.0"
}
}</token>
-
url末尾不要加.git(虽部分情况 fallback,但 Composer 官方文档明确建议省略) - Token 放 URL 里是唯一可靠方式;
auth.json的http-basic对 Gitee 无效(Gitee 不走 HTTP Basic 认证) - 如果用 CI/CD,把 Token 塞进环境变量再注入 URL,避免硬编码
SSH 方式更干净,但要注意密钥加载时机
如果你已配置好 SSH 密钥对,并把公钥添加到 Gitee 账户,可以用更简洁的 SSH URL:
{
"repositories": [
{
"type": "vcs",
"url": "git@gitee.com:your-org/hyperf-utils"
}
]
}
- 确保运行
composer install的用户能读取~/.ssh/id_rsa,且ssh-agent已启动并加载了密钥(ssh-add -l可验证) - SSH 方式完全不读
auth.json,哪怕它存在也无影响 - 内网部署时,若无法用 SSH agent(如容器无交互),优先退回 HTTPS + PAT
版本匹配失败?检查 Git tag 和 stability 设置
Composer 查私有 vcs 仓库,只认 Git 的 tag(如 v1.2.3)和分支名(如 dev-main),完全忽略包内 composer.json 的 version 字段。
- 没打任何 tag 的仓库,唯一可用版本是
dev-main(旧版叫dev-master),但必须在根composer.json加"minimum-stability": "dev",否则默认跳过 - 打了
v1.0.0tag,就写"your-org/hyperf-utils": "^1.0";写成"1.0.0"也行,但推荐用波浪线 - 分支名含
dev-前缀才被识别为开发版,比如dev-feature/login可用"dev-feature/login"引用
最容易被忽略的是:Gitee 上推了 tag,但没 git push --tags,或者用了轻量 tag(git tag v1.0.0)而非附注 tag(git tag -a v1.0.0 -m "release")——两者都能被 Composer 识别,但附注 tag 更规范、CI 日志更清晰。










