镜像源和缓存目录是两套独立机制，不能互相替代；换镜像后需执行composer clear-cache清除旧元数据缓存，否则仍请求原地址；Docker构建中vendor层复用关键在于先COPY composer.json/composer.lock再RUN install，且二者须已提交Git、未被.dockerignore过滤。
镜像源和缓存目录是两套独立机制，不能互相替代，也不能靠改一个就解决下载慢或构建卡的问题。 你配了阿里云镜像但composer install还是慢，大概率不是镜像没生效，而是缓存目录被污染、没命中，或者 Docker 构建层顺序错了。
为什么换了镜像还要清缓存？
Composer 缓存的是元数据快照（比如 repo/packagist.org/packages.json），这些文件里硬编码着源地址和 hash。哪怕你刚用 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 配好，旧缓存里仍存着指向 https://packagist.org 的路径和校验值。
-
composer clear-cache会删掉~/.composer/cache/repo/下所有元数据，强制下次请求重新拉镜像源的 packages.json - 不清缓存，
composer update可能卡在 “Loading composer repositories”，或报Package not found—— 实际是校验失败，不是包真没了 - 验证是否真走镜像：加
-vvv跑一次composer install，看到类似GET https://mirrors.aliyun.com/composer/p2/monolog/monolog.json才算成功
项目级镜像配置为什么总被忽略？
只要项目根目录的 composer.json 里有 repositories 字段（哪怕只写了 "packagist.org": false），全局镜像配置就完全失效 —— 不是优先级低，是直接跳过。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 常见于 Laravel 脚手架或团队模板，它们自带空
repositories块，导致你配的全局镜像形同虚设 - 正确写法必须带
type参数：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意中间那个composer是 type，不是命令名） -
url末尾不能带斜杠：https://mirrors.tuna.tsinghua.edu.cn/composer/❌，https://mirrors.tuna.tsinghua.edu.cn/composer✅ - CI 中别在 install 前跑
composer config -g，它会覆盖项目级配置；应确保composer.json已提交且含正确repositories
Docker 构建中缓存目录和镜像源怎么配合？
容器里默认不继承宿主机的 ~/.composer/cache，就算你本地配了镜像、清了缓存，Docker 构建时仍是干净环境。关键不是“怎么挂载缓存”，而是“怎么让 vendor 层稳定复用”。
-
COPY composer.json composer.lock ./必须放在RUN composer install之前，且不能和其他文件混在一起 COPY -
composer.json和composer.lock必须已提交到 Git，不能被.dockerignore过滤掉 - 建议在
RUN composer install里加--no-scripts --no-plugins --prefer-dist，排除钩子执行带来的不确定性 - 如果用了
COMPOSER_CACHE_DIR，设为/dev/null更稳妥，把状态完全交给 Docker 层管理，避免引入额外变量
缓存目录路径改了但没提速？
改 cache-dir 只影响本地开发体验，对 CI 构建或 Docker 分层无实质帮助。缓存只加速“已下过的包”的解压和安装，首次拉取、版本升级、require 新包时依然要走网络。
- 用
composer config --global cache-dir查当前路径；改完不会自动迁移旧缓存，得手动搬或清掉 - 环境变量
COMPOSER_CACHE_DIR优先级高于配置文件，适合 CI 临时指定，比如COMPOSER_CACHE_DIR=/tmp/composer-cache composer install - 别信
composer config -g输出——它只告诉你字段值，不告诉你实际发了什么请求；真正要看-vvv日志里的GET地址 - 某些镜像源（如已停服的
packagist.phpcomposer.com）响应异常时，Composer 会绕过缓存重试，看起来像“缓存失效”
最常被忽略的其实是：镜像源解决的是“从哪下”，缓存目录解决的是“下完存哪”，而 Docker 分层解决的是“下完要不要重下”。三者逻辑分离，但必须协同才能见效。
