Composer install仍走缓存是因为默认优先复用~/.composer/cache中的包，即使已配置国内镜像源；必须配合--no-cache、clear-cache或COMPOSER_CACHE_DIR=/dev/null才能强制跳过缓存并从镜像源重新下载。
为什么 composer install 还是走缓存，没从镜像源重新下载？
因为 Composer 默认会优先复用本地缓存（~/.composer/cache），哪怕你已配置了国内镜像源（如阿里云、腾讯云），它也不会自动跳过缓存重拉包。这导致你改了源、清了镜像配置，却依然下载慢或报错——实际是旧缓存里的包在作祟。
- 缓存命中时，
composer install根本不发 HTTP 请求，镜像源配置形同虚设 - 即使
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/生效，缓存仍优先 - 某些私有包或带
dist的压缩包，缓存内容可能已损坏但未被校验
强制跳过缓存的三种实操方式
真正绕开缓存，得让 Composer 显式放弃读取或写入缓存目录。以下方法按推荐顺序排列：
-
最常用：加
--no-cache参数，如composer install --no-cache或composer update --no-cache—— 它禁用整个缓存读写，所有包都走网络请求 -
更彻底：临时清空缓存再执行，
composer clear-cache && composer install—— 注意clear-cache会删掉所有缓存（包括已验证的包），后续操作又会重建，适合调试阶段 -
精准控制：用
COMPOSER_CACHE_DIR环境变量指向空目录，比如COMPOSER_CACHE_DIR=/dev/null composer install（Linux/macOS）或set COMPOSER_CACHE_DIR=NUL && composer install（Windows）—— 这能避免误删真实缓存，适合 CI 脚本
国内镜像源配置是否生效，怎么快速验证？
别只看 composer config -g repo.packagist 输出，得观察实际请求行为。最直接的办法是启用详细日志并抓包：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer install -vvv --no-cache 2>&1 | grep "Downloading"，确认 URL 是https://mirrors.aliyun.com/composer/或类似路径，而非https://packagist.org/ - 如果看到
Downloading https://packagist.org/...，说明镜像源没生效：检查是否用了-g全局配置但当前项目有composer.json中的repositories覆盖了全局设置 - 腾讯云镜像已停服（2023 年底），阿里云和华为云目前稳定；若用
https://packagist.phpcomposer.com，该源早已失效，会 fallback 到官方源
缓存跳过后的副作用要注意什么？
跳过缓存不是银弹，尤其在团队协作或 CI 环境里：
- 首次安装变慢：每个包都要重新下载、解压、校验，没有缓存加速
- 重复下载浪费带宽：同一台机器多次执行
--no-cache，不会复用前一次结果 - 某些插件（如
hirak/prestissimo）在无缓存时可能触发并发下载 bug，建议先卸载：composer global remove hirak/prestissimo - 如果项目依赖大量私有包且镜像源未同步最新版本，跳过缓存反而会暴露镜像滞后问题
真正要解决的，其实是“缓存脏”和“镜像不同步”两个独立问题：前者靠 --no-cache 或 clear-cache，后者得换更及时的镜像源或联系镜像维护方。
