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 输出，得观察实际请求行为。最直接的办法是启用详细日志并抓包：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
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，后者得换更及时的镜像源或联系镜像维护方。
