Composer连不上Bitbucket私有仓库主因是认证配置混乱：必须统一用bitbucket-oauth（配App Password）或http-basic，不可混用；URL须为HTTPS+vcs+.git后缀；包名须与仓库composer.json中name完全一致；CI推荐用COMPOSER_AUTH环境变量；报错先清缓存再-vvv查Authorization头。
Composer 连不上 Bitbucket 私有仓库，90% 是因为没配对认证方式——bitbucket-oauth 和 http-basic 不能混用，SSH 和 HTTPS 也不能自动切换；必须先明确走哪条路，再严格匹配配置项、URL 格式、权限和缓存状态。
composer config bitbucket-oauth 必须用 App Password，不是账号密码
Bitbucket Cloud 不接受主账号密码，也不认旧版 OAuth consumer，只认你个人账号下生成的 App Password，且必须勾选 Repositories: Read。这个密码只显示一次，复制后立刻保存，刷新页面就没了。
-
composer config --global bitbucket-oauth.bitbucket.org <your-app-password>是唯一推荐写法，别手改auth.json - 域名必须是
bitbucket.org，写成www.bitbucket.org或api.bitbucket.org都无效 - 执行后不回显，用
composer config --auth --list查看是否写入成功 - 如果提示
This app password has been revoked，说明已被删除或重生成，得换新的
repositories 中 URL 必须是 HTTPS + vcs 类型，不能是网页链接
即使 bitbucket-oauth 配好了，如果 composer.json 里 repositories 的 URL 是 https://bitbucket.org/xxx/yyy（缺 .git）或直接塞进 require，Composer 就不会触发认证流程，仍按匿名请求处理，结果就是 Could not fetch https://api.bitbucket.org/2.0/repositories/...。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确写法：
{"type": "vcs", "url": "https://bitbucket.org/username/repo.git"} - URL 必须带
.git后缀，且是完整 Git 克隆地址，不是浏览器打开的页面地址 - 包名（
require中的vendor/name）必须和私有仓库内composer.json的name字段完全一致，包括大小写 - 别用 SSH 地址混在 HTTPS 配置里，比如
git@bitbucket.org:xxx/yyy.git配了bitbucket-oauth也无效
HTTP Basic Auth 走的是 http-basic，不是 bitbucket-oauth
如果你看到别人用 http-basic.bitbucket.org，那是另一套路径：它要求你在 auth.json 里手动填 username 和 password，而且 password 仍然是 App Password。这套和 bitbucket-oauth 命令互斥，不能同时存在，否则 Composer 会优先用 http-basic 并忽略 bitbucket-oauth 配置。
- 全局设 Basic Auth：
composer config --global http-basic.bitbucket.org username your-app-password - 该命令会往
auth.json写入{"bitbucket.org": {"http-basic": {"bitbucket.org": {"username": "...", "password": "..."}}}} - 一旦用了
http-basic，bitbucket-oauth就失效；反之亦然 - CI 环境建议用环境变量
COMPOSER_AUTH注入整个auth.json内容，避免磁盘写权限问题
报 401/403 时先清缓存，再看 -vvv 日志里有没有 Authorization 头
Composer 会缓存未授权的响应，哪怕你刚配好凭证，它也可能复用旧的失败请求头。不清理缓存，重试多少次都一样。
- 第一步永远是
composer clear-cache - 第二步加
-vvv：例如composer install -vvv 2>&1 | grep -i authorization，确认是否发出Authorization: Basic ...或Authorization: Bearer ... - 如果没 Authorization 头，说明
repositoriesURL 格式错、type没设成vcs，或者包名对不上 - 如果头发了但还是 403，重点查 App Password 权限是否漏了
Repositories: Read，或用了团队账号生成的密码（必须是拥有仓库读权限的个人账号）
最容易被忽略的是：Bitbucket Server（自建版）根本不支持 bitbucket-oauth，只能走 http-basic；而 Packagist 镜像服务和 bitbucket-oauth 是两件事——镜像管元数据，代码拉取仍直连 Bitbucket，认证一个都不能少。
