Composer报“未绑定域名”实为auth.json域名与repositories URL严格不匹配所致，需逐字比对协议、端口、子域名及主域名，确保完全一致，并验证认证类型（http-basic/bearer/gitlab-oauth）与服务端要求相符。
Composer 报 “未绑定域名” 是因为 auth.json 域名不匹配
这不是 DNS 或 Nginx 配置问题，而是 Composer 在做 HTTP Basic 认证时，把 auth.json 里存的凭证和 repositories 中 URL 的域名做了严格比对——只要协议、端口、子域名或主域名有一处不一致，就拒绝发送凭证，最终返回 401/403，表现为你看到的“未绑定域名”类提示（实际错误日志里常是 Authentication failed 或 401 Unauthorized）。
-
repositories里写的是"https://pkg.mycompany.com"，但auth.json里配的是"mycompany.com"→ 不匹配 - URL 是
"https://pkg.mycompany.com:8080"，而auth.json没写端口 → 不匹配 - 用了
"http://"协议，但凭证存在https://域名下 → 不匹配 - CI 环境中通过
COMPOSER_AUTH注入，但 JSON 里域名漏了www.或多了api.→ 同样失败
验证方式：运行 composer config -g --list | grep http-basic，再对照 composer.json 里的 repositories URL，逐字比对域名部分。
私有源必须用 http-basic 还是 bearer？看服务端要求
不是所有私有源都支持同一种认证方式。阿里云私有源、Satis、Artifactory 默认走 http-basic；GitLab 私有包推荐用 gitlab-oauth；某些内部 Nexus 或自建 Composer 服务可能只认 bearer 或自定义 header。
- HTTP Basic：适用于用户名+密码或 token 当密码用的场景，命令是
composer config http-basic.pkg.mycompany.com user token - Bearer Token：适合纯 token 认证，命令是
composer config bearer.pkg.mycompany.com abc123... - GitLab OAuth：专用于 GitLab，命令是
composer config gitlab-oauth.gitlab.mycompany.com abc123... - 自定义 Header：少数私有服务要求
X-Api-Key，得用composer config custom-headers.pkg.mycompany.com "X-Api-Key: abc123"
错配认证类型会导致 401 且无明确提示——Composer 只静默跳过该源，日志里可能只显示 Skipping repository ... due to missing provider。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
CI 环境下私有源认证失效的三个硬性条件
本地能装，CI 报认证失败，90% 是因为没同时满足这三点：
-
COMPOSER_AUTH环境变量必须在 job 启动时就生效，不能在脚本中间 export（GitHub Actions 中要写在env:下，不是run:里） -
COMPOSER_AUTH的 JSON 结构必须合法，且域名与repositories完全一致（包括大小写、端口、协议） - PHP 进程启动前，
openssl.cafile路径必须正确；否则 HTTPS 请求会因证书校验失败 fallback 到未认证请求，结果仍是 401
调试技巧：在 CI step 里加一行 php -r "print_r(openssl_get_cert_locations());"，确认 default_cert_file 是否可读；再加 cat ~/.composer/auth.json（如果用了文件方式），看内容是否被正确写入。
为什么私有源 URL 返回 404？不是网络问题，是镜像拦截
如果你同时配置了阿里云镜像和私有源，但把镜像写在 repositories 数组前面，Composer 就会先拿包名去镜像查——而镜像根本不代理私有请求，直接返回 404。这不是超时，是明确拒绝。
- 必须把私有源放在
repositories数组**第一位**：[{"type":"composer","url":"https://pkg.mycompany.com/"},{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}] -
repo.packagist全局配置对私有源无效，它只接管packagist.org流量 - 私有源根目录必须能访问到合法的
packages.json，且响应头含Content-Type: application/json；用curl -I https://pkg.mycompany.com/packages.json验证状态码和头信息
最容易忽略的一点：私有源的 packages.json 必须显式列出你 require 的包名（如 "mycompany/utils"），不能靠 Composer “猜”。
