关键在于配置 repositories 并设 type 为 vcs，确保 Git 地址可访问、包名一致、认证正确（SSH 或 auth.json），且 require 时需手动添加或指定 --repository-url。
怎么让 composer 读到私有 Git 仓库的包
关键不是“加仓库”，而是让 composer 知道：这个包的源不在 Packagist，得去某个 Git 地址拉。直接在 composer.json 里写 "repositories" 是最常用方式，但必须配对使用 "type": "vcs"，否则会被忽略。
- Git 仓库地址必须能被当前机器 SSH 或 HTTPS 访问（比如
git@github.com:org/private-package.git或https://gitlab.example.com/group/pkg.git） -
"repositories"要放在根级，不能嵌套在"require"里 - 如果用 HTTPS 且仓库需要认证，得提前配置
git config --global credential.helper store或用auth.json（见下一条） - 私有包的
name（如"myorg/utils"）必须和composer.json里声明的一致，composer不会自动推断
为什么 composer install 报错 “Could not fetch” 或 “401”
90% 是认证没走通。Composer 本身不存密码，它依赖 Git 工具链或 auth.json 提供凭据。报错时先看完整信息里有没有 Cloning into... 或 remote: Invalid username or password 这类线索。
- 用 SSH 方式？确认本地
ssh -T git@github.com（或对应域名）能通，且私钥已加载进ssh-agent - 用 HTTPS 方式？把
auth.json放在项目根目录或COMPOSER_HOME目录下，内容类似：{"http-basic": {"gitlab.example.com": {"username": "token", "password": "glpat-xxx..."}}} - 别把 token 写进
composer.json—— 它可能被提交到公开仓库 - 某些 Git 托管平台（如 Gitea）要求在 URL 里带 token，例如
https://token:x-oauth-basic@gitea.example.com/user/pkg.git，这时auth.json反而会冲突
composer require 找不到私有包，但 composer install 可以装
因为 require 命令默认只查 Packagist，不会主动扫描你配置的私有 repositories，除非包名已存在于本地 composer.lock 或已声明在 require 里。这是设计行为，不是 bug。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确流程是：先手动编辑
composer.json的"require"，加上"myorg/utils": "^1.0"，再运行composer update myorg/utils - 或者用
composer require myorg/utils --repository-url=https://gitlab.example.com/api/v4/groups/myorg/-/projects/utils（注意：该 URL 是 GitLab API 地址，不是 Git 克隆地址） - 如果私有包没打 Git tag，
composer默认只认stable版本，得在require后加"@dev"，或设"minimum-stability": "dev"（不推荐线上用）
私有包更新后 composer update 不拉最新 commit
Composer 缓存的是包的 dist 归档（zip/tar），不是实时 Git 拉取。它根据 composer.lock 里记录的 commit-ref 或 dist.shasum 决定是否更新，而不是看远程分支 HEAD。
- 强制重拉：删掉
vendor/myorg/utils和composer.lock里对应条目，再composer update myorg/utils - 更稳的做法：给私有包打语义化 tag（如
v1.2.3），然后在require中指定版本，避免依赖dev-main这类易变引用 - 如果用
"type": "package"手动定义仓库（非 vcs），记得每次改了包内容就得同步改"dist"的"url"和"shasum"，否则缓存永远不更新
私有包最难缠的从来不是配置，而是团队里谁该维护 auth.json、谁负责打 tag、CI 流水线用什么凭据拉代码——这些事没对齐，composer 再听话也没用。
