composer镜像本身不实现lru缓存，真正缓存发生在本地文件系统~/.composer/cache或%appdata%\composer\cache，仅存储.zip归档和元数据，所有“命中”依赖文件存在、哈希校验及上下文一致，而非内存淘汰机制。
Composer镜像本身不缓存，缓存全在本地磁盘
镜像源（比如阿里云、腾讯云）只是HTTP代理，不存包、不淘汰、不管理LRU——它不实现任何缓存逻辑。所谓“镜像缓存”是误称。真正起作用的缓存只在你本地：~/.composer/cache（Linux/macOS）或%APPDATA%\Composer\cache（Windows）。这个目录下分三个子目录：files（存.zip）、repo（存packages.json等元数据）、vcs（存Git裸库）。所有“命中”都靠文件存在+哈希校验，不是内存里按访问时间排序的淘汰。
缓存失效不是因为LRU踢出，而是文件内容或上下文变了
很多人看到“刚装过的包又重下”，以为是缓存被LRU清掉了。其实根本没LRU这回事。触发重下只有几种真实原因：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer.lock里记录的版本号或hash变了（哪怕只改了一个字符） - PHP版本不一致，或
config.platform.php声明与当前环境不匹配 -
repo/里缓存的packages.json过期（默认15分钟），且网络请求成功刷新了元数据 - 执行了
composer clear-cache——这是全删，不是按热度清理 - Docker构建中每次清空
vendor/，导致即使files/有zip也白搭，还得解压+install
换镜像后缓存不生效？先查配置有没有真正写对
90%的“镜像没用上”问题，根源是配置静默失败。常见错误包括：
- 命令写成
composer config -g repos.packagist（多一个s），Composer 2.2+直接忽略，不报错也不 fallback - URL漏了末尾
/，比如https://mirrors.aliyun.com/composer→ 实际请求变成/composerpackages.json，返回404后自动弃用该镜像 - 项目级
composer.json里写了"repositories": []，全局配置repo.packagist彻底失效，且无提示 - 验证是否生效不能只看命令回显，要运行
composer config -g repo.packagist，输出必须是完整JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
CI/CD里缓存总失灵？关键不在镜像，而在构建流程设计
Docker多阶段构建中，缓存失效往往和镜像无关，而是COPY顺序和缓存策略错配：
- 如果
COPY . /app放在composer install之前，哪怕只改了README.md，整个依赖安装层就全废 - 正确做法是先
COPY composer.json composer.lock ./，再composer install --no-dev --optimize-autoloader，最后才COPY . /app - GitHub Actions等CI平台应缓存
~/.composer/cache，而不是只缓存vendor/——前者省下载，后者省解析和写入 - 用
COPY --from=builder /app/vendor /app/vendor比反复composer install更稳，跳过所有依赖解析阶段
composer.lock的锁定效力和项目级repositories字段的绝对优先级——它们不商量，也不警告。
