Composer缓存清理解决私有仓库依赖异常-composer-PHP中文网

私有仓库404或版本拉不到，首要排查缓存污染：composer clear-cache不清理私有源元数据缓存，需手动删除~/.composer/cache/repo/https---your-private-repo.com/目录；同时确认repositories中url末尾带/、type为"composer"，并清除vendor/composer/installed.json和composer.lock以避免旧dist url锁定。

composer缓存清理解决私有仓库依赖异常

私有仓库404或版本拉不到？先确认缓存是否污染了元数据

私有仓库（如 Satis、Private Packagist、GitLab Package Registry）出问题，composer clear-cache 往往不够——它删的是 ~/.composer/cache/files/ 和 repo/ 下的快照，但私有源的 packages.json 可能被缓存在 ~/.composer/cache/repo/https---your-private-repo.com/ 这类路径下，而 clear-cache 不保证清掉所有子目录（尤其当 URL 含端口、路径带特殊字符时）。

常见现象包括：404 Not Found、Could not parse version constraint、明明打了新 tag 却始终装旧版。

运行 composer config --global cache-dir 确认缓存根路径
进 repo/ 子目录，用 ls -d https*private*（Linux/macOS）或 Get-ChildItem "$env:APPDATA\Composer\Cache\Repo" -Directory -Filter "https*private*"（PowerShell）找对应仓库缓存目录
直接 rm -rf 或 Remove-Item -Recurse -Force 整个匹配目录，别只删里面的 packages.json
顺手检查 composer.json 中 repositories 的 URL 是否末尾带 /：少一个斜杠，Composer 会当成不同源，缓存不共享也不覆盖

认证失效导致私有包下载中断？缓存里可能存着过期的 401 响应

GitHub Token 过期、GitLab Personal Access Token 权限不足、或私有仓库启用了 IP 白名单后本地网络变更，都可能导致 Composer 把 HTTP 401/403 响应缓存成“不可用”的元数据。此时 composer install 会跳过该源，甚至静默回退到 Packagist。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

删完私有源缓存目录后，**必须删 vendor/composer/installed.json**：它记录了上次成功安装的包快照，含来源信息；不清它，Composer 可能继续用旧的、已失效的安装记录
执行 composer update --dry-run -v，观察日志中是否出现 Reading packages.json from https://your-private-repo.com/packages.json —— 没这行，说明源没生效
若仍报 401，检查 composer config -g github-oauth.github.com 或 gitlab-token 配置是否正确，Token 是否有 read_package_registry 权限
临时加 -vvv 跑 composer update，看请求头是否带 Authorization：没带，说明认证配置未加载

私有包更新后 vendor/ 里还是旧文件？不是缓存问题，是 lock 文件锁死了 dist URL

私有仓库改了包的 dist.url（比如从 https://satis.example.com/dist/foo-1.2.0.zip 换成 https://cdn.example.com/foo-1.2.0.zip），但 composer.lock 里还存着旧 URL 和旧 dist.shasum，Composer 就会死守旧地址下载，哪怕缓存全清、源也刷新了。

composer.lock 中每个包的 dist 段落硬编码了 url、shasum、type，这些值不随源更新自动变
安全做法是：删 composer.lock + 删 vendor/，再跑 composer update --no-cache --prefer-dist
CI 环境中务必加 --no-cache：否则 Docker 层可能复用旧缓存 ZIP，解压后仍是旧代码
如果项目不允许升级其他依赖，用 composer update vendor/private-package --no-cache 精准更新单个包，避免波及整个树

为什么清完缓存还走错镜像？检查 repo.packagist 键名和 type 值

私有仓库配置和 Packagist 镜像共存时，最容易踩的坑是键名写错：repos.packagist（多一个 s）或漏写 "type": "composer"，会导致配置写进无效字段，Composer 完全忽略。

运行 composer config --global --list | grep repo，确认输出里有 repo.packagist（不是 repos）且其值为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
私有仓库必须显式声明 "type": "composer"，哪怕 URL 是 Git 地址——因为 Composer 2.x 不再自动推断类型
URL 结尾必须带 /：写成 "https://satis.example.com" 和 "https://satis.example.com/" 是两个不同缓存 key，后者才匹配实际响应头中的 Content-Location
删缓存后立刻跑 composer install -vvv 2>&1 | grep "Downloading https"，确认请求发出的域名是你期望的私有源

私有仓库的问题往往卡在「缓存路径不一致」「认证响应被缓存」「lock 文件固化旧 dist」这三点上，而不是单纯下载失败。动手前先 composer config --global cache-dir 和 composer install -vvv 看两眼真实路径与请求链路，比盲目清缓存高效得多。