Composer中文镜像与Composer私有包鉴权策略协同-composer-PHP中文网

阿里云等镜像仅缓存packagist.org公开包，对internal/auth-sdk等私有包无感知，composer会绕过镜像直连私有源；若私有源未正确声明、认证缺失或url不匹配，就会报“could not find package”。

composer中文镜像与composer私有包鉴权策略协同

中文镜像和私有包鉴权不是二选一，而是必须隔离处理的两件事：镜像只管公开包加速，私有包必须走独立源+独立认证，混在一起就全崩。

为什么给私有包配阿里云镜像会报“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 Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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