Gitee 不能直接作为 Composer 私有仓库，因其不提供 packages.json 接口；需用 Satis 等工具聚合 Gitee 代码源并生成静态仓库，Gitee 仅作 VCS 托管。
不能直接用 Gitee 当 Composer 私有仓库，它不是 Packagist 兼容的镜像服务，也不提供 packages.json 接口。你真正需要的是一个能聚合、索引、分发私有包的中间服务——比如 satis 或 toran-proxy（已停更），而 Gitee 只能作为 Git 代码托管源被这类服务拉取。
为什么 composer.json 里写 "type": "vcs" + Gitee 地址不等于“私有仓库”
这种写法只是让 Composer 临时从某个 Git 仓库按需克隆代码，属于「单包直连」，不是仓库级管理：
- 每次
composer install都会走 Git 协议拉取，没缓存、无版本元数据聚合、无法搜索或浏览包列表 - 所有依赖必须显式声明在
require里，不能像 Packagist 那样靠name自动发现 - CI/CD 中若未配置 SSH 或 Token，
Could not read from remote repository错误几乎必现 - 多人协作时，不同人本地缓存路径、Git 凭据状态不一致，会导致
composer update结果不可复现
用 satis 构建真正可用的私有仓库，Gitee 仅作代码源
satis 是静态生成型仓库工具，它定期扫描你指定的 Gitee 仓库（支持 SSH 或 HTTPS），把它们的 tag/branch 解析成标准 packages.json，输出为纯静态文件供 Composer 拉取。
Lovefromio Github
下载
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 确保 Gitee 仓库已打 tag（如
v1.0.0），satis只认带语义化版本的 tag，dev-main这类分支名默认不索引 -
satis.json中repositories字段填 Gitee 的 HTTPS 或 SSH 地址，但必须保证运行satis build的机器能免密访问这些仓库（推荐用 Deploy Keys） - 内存不足是高频报错：
Fatal error: Allowed memory size of 134217728 bytes exhausted，改php.ini的memory_limit至少512M，或加-d memory_limit=1G参数启动 - 构建命令必须指定输出目录，且该目录要由 Web 服务器（Nginx/Apache）直接可访问：
php bin/satis build satis.json web/
项目中如何安全接入这个私有仓库
别动全局配置（composer config -g），避免污染其他项目。在项目根目录执行：
composer config repositories.myprivaterepo composer https://packagist.xxx.top
这条命令会把配置写进当前项目的 composer.json 的 repositories 字段。注意顺序：
- 如果同时用了阿里云镜像和你的私有站，
myprivaterepo必须排在packagist条目之前，否则 Composer 会跳过它去公网找包 - 私有包的
name（如sentiger/wphp）必须和 Gitee 仓库的命名空间完全一致，大小写敏感 - 首次安装前清掉本地缓存：
composer clear-cache，否则旧的失败记录可能干扰解析
真正麻烦的从来不是搭建步骤，而是权限链路：Gitee 的 Deploy Key → satis 构建机的 Git 访问 → Web 服务器对 web/ 目录的读取权限 → 项目中 repositories 的加载顺序。漏掉任意一环，composer install 就会在某个环节静默失败。
