答案：必须先删vendor和composer.lock再清缓存，因锁文件硬编码旧地址、项目级repositories字段会屏蔽全局镜像、镜像配置格式错误（如缺斜杠或type未设）导致静默回退官方源。
项目迁移后 composer install 报错，大概率不是缓存没清干净，而是旧环境残留的配置、锁文件或镜像污染在作祟。直接 composer clear-cache 往往无效，甚至掩盖真正问题。
为什么清了 ~/.composer/cache 还报错？
本地缓存只是表象。项目迁移常伴随以下真实残留：
-
composer.lock里硬编码了旧 provider 地址（比如已失效的私有源或过期镜像路径），不删它，Composer 就会反复尝试请求不存在的 URL - 项目根目录
composer.json中残留了"repositories"字段（哪怕只是空数组[]），会彻底屏蔽全局镜像配置 - 旧环境配置的镜像 URL 末尾缺
/或 type 没写composer，导致 Composer 静默 fallback 到官方源，但composer.lock仍按旧规则校验 checksum - 某些镜像（如早期 PHPChina 源）返回带 BOM 头或 HTML 页面的元数据，
clear-cache后仍会复用损坏的 JSON 缓存
废弃缓存该删哪些？怎么删才安全？
别只盯着 ~/.composer/cache。按优先级操作：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先删项目级残留：
rm -rf vendor/ composer.lock—— 这是必须项，否则 checksum mismatch 类错误无法根除 - 再清全局缓存：
composer clear-cache，Windows 用户额外手动删%LOCALAPPDATA%\Composer\cache - 谨慎清理 Git 缓存：
rm -rf ~/.composer/cache/vcs/*（安全，下次需要自动重建）；但绝不要碰~/.composer/cache/repo/packagist.org/，这是核心索引，删了会导致首次composer update明显变慢 - 确认无后台进程：手删前确保没有
composer进程在运行，否则可能触发Corrupted cache file报错
镜像配置失效？检查这三处真实生效点
迁移后镜像“看起来配了却没走”，往往卡在这几个地方：
- 运行
composer config -g repo.packagist，输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null或仍是https://packagist.org，说明根本没写成功 - 检查项目
composer.json是否含"repositories"字段 —— 只要存在，全局配置就完全失效，哪怕它内容为空 - 用
composer install -vvv 2>&1 | head -n 10 | grep Downloading看第一行真实请求 URL，别信config输出，日志里的地址才是真相
最易被忽略的点：迁移后若用不同用户（如从 root 切到 www）执行命令，全局配置读不到；CI/宝塔环境务必用对应用户重配 composer config -g，或干脆改用项目级配置（composer config repo.packagist composer https://mirrors.aliyun.com/composer/），避免权限陷阱。
