阿里云等镜像仅缓存packagist.org公开包，对internal/auth-sdk等私有包无感知，Composer会绕过镜像直连私有源；若私有源未正确声明、认证缺失或URL不匹配，就会报“Could not find package”。
中文镜像和私有包鉴权不是二选一，而是必须隔离处理的两件事：镜像只管公开包加速，私有包必须走独立源+独立认证，混在一起就全崩。
为什么给私有包配阿里云镜像会报“Could not find package”
阿里云、清华等镜像只同步 packagist.org 上的公开包元数据，对 internal/auth-sdk 这类私有包完全无感知。Composer 会跳过镜像，直连你声明的私有源 URL；但如果这个 URL 写错、没认证、或服务没响应，就会卡在 Cloning 或直接报错。
- 现象：执行
composer require internal/auth-sdk后提示Could not find package或长时间无响应 - 原因不是镜像没配好，而是私有源本身没被正确声明——
repositories数组里缺了它，或类型写成"type": "composer"却指向 Git 地址 - 错误配置示例：
{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}下面又跟一个私有 Git 地址，但没加"type": "vcs" - 真正要做的，是在
repositories顶部显式加一条私有源，类型为vcs或composer（取决于后端是 GitLab 还是 Satis）
auth.json 放哪、怎么写、权限多少才生效
auth.json 不是“写了就能用”，位置、字段名、权限三者错一个，Composer 就静默跳过——你看到的 Authentication required 或 401 Unauthorized，八成是它根本没读到凭据。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只认两个路径：项目根目录（和
composer.json同级），或全局~/.composer/auth.json；放在vendor/或子目录下无效 - GitLab 场景必须用
"gitlab-token"字段，不是http-basic；写成{"gitlab.example.com": "glpat-xxx"}才对 - 私有 Composer 源（如 Satis）才用
http-basic，格式为{"http-basic": {"repo.example.com": {"username": "api", "password": "token123"}}} - Linux/macOS 下权限必须是
600：运行chmod 600 auth.json，否则 Composer 直接忽略
混合源顺序怎么排才不冲突
Composer 查源是线性扫描，顺序即优先级。私有源必须最前，公开镜像居中，官方源仅作兜底且需显式开关控制，否则要么私有包拉不到，要么公共包被污染。
- 正确顺序示例：
"repositories": [{"type":"vcs","url":"https://gitlab.example.com/myorg/utils"},{"type":"composer","url":"https://mirrors.aliyun.com/composer/"},{"packagist.org": false}] - 不能把私有源和公开镜像混写成同一类型（比如都写
"type": "composer"），否则私有源因认证失败卡住时，整个命令会超时中断，不会往下查 -
"packagist.org": false必须写在repositories数组里，作为独立项；写成"packagist": false在顶层会禁用所有 packagist 类型源，包括你自己的私有 Composer 源 - 运行
composer config repositories可确认当前实际生效的源列表，别靠猜
JWT 鉴权怎么塞进 Composer 的 auth.json
Composer 本身不支持 JWT，所谓“JWT 鉴权”其实是反向代理（Nginx/Traefik）的事。你填进 auth.json 的，只能是它能识别的格式——而唯一兼容 JWT 的写法，是把 token 当作 Basic Auth 的 username，password 留空。
- 错误做法：在
auth.json里加"jwt-token"字段，或往composer.json的repositories里塞"options": {"auth": {"bearer": "xxx"}}—— 全部静默忽略 - 正确写法（前提是 Nginx 已配置 JWT 校验并重写为
Authorization: Basic base64(token:)）：{"http-basic": {"repo.example.com": {"username": "eyJhbGciOi...", "password": ""}}} - 域名 key 必须和仓库 URL 的 host 完全一致：如果 URL 是
https://repo.example.com:8080，key 就得写"repo.example.com:8080"，少端口或多 www. 都不匹配 - 验证是否生效：用
curl -v -H "Authorization: Basic $(echo -n 'eyJhbGciOi...:' | base64)" https://repo.example.com/packages.json看是否返回 200
最容易被忽略的是：镜像源和私有源之间没有“继承关系”。你配了阿里云镜像，不代表私有包也能自动走它；你写了 auth.json，也不代表 Composer 会把它发给所有域名——它只匹配 repositories 里声明过的源 URL 的 host 部分，一个字符都不能差。
