Composer中文镜像环境下的Composer包元数据本地持久化-composer-PHP中文网

根本原因是composer默认10分钟缓存packages.json元数据，即使镜像源已更新，本地旧缓存未过期就不会发起http请求；验证需用composer update -vvv | grep "get"，刷新元数据应使用composer update --refresh。

composer中文镜像环境下的composer包元数据本地持久化

为什么改了镜像源，composer update 还拉不到新版本

根本不是命令没执行，而是 Composer 正在读取本地缓存的 packages.json 元数据——它默认 10 分钟（cache-ttl=600）不过期，哪怕阿里云镜像站上已同步了 monolog/monolog 的 3.6.0，你本地缓存里还是旧快照，composer update 就压根不发请求。

常见误判：看到 composer config -g repo.packagist 返回了正确 URL，就以为万事大吉。其实只要 ~/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json 没过期，它连 GET 都不会发。

验证是否真走镜像：运行 composer update -vvv | grep "GET"，确认日志里出现的是 mirrors.aliyun.com 而非 packagist.org
强制刷新元数据层（推荐）：用 composer update --refresh（Composer ≥ 2.5），它只清 repo/ 下的元数据文件，不动已下载的 ZIP 包
老版本（rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
别信 composer clear-cache —— 它清整个缓存，但下次 install 仍可能复用旧 ZIP，和元数据刷新无关

如何让 packages.json 元数据“常驻本地”且自动更新

持久化 ≠ 一劳永逸地拷贝一份 JSON 文件，而是让 Composer 在每次需要时，能从可信镜像源拉取最新版并落盘到固定路径，且后续命令默认信任它。

关键不在“存”，而在“信”。Composer 默认只信任远程响应的元数据，除非你让它明确知道：这个本地文件就是权威来源。

确保镜像配置真正生效：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（注意中间的 composer 是强制 type 参数，缺了就静默 fallback）
调低元数据过期时间（开发环境）：composer config -g cache-ttl 30，30 秒后即触发重拉；CI 环境建议保持默认或设为 600，避免镜像站限流
URL 必须以 / 结尾，否则会拼出 https://mirrors.aliyun.com/composerpackages.json 导致 404
项目级 repositories 字段会完全屏蔽全局镜像——哪怕只是空数组 "repositories": []，也要检查并删掉

离线场景下，怎样让 composer install 完全不碰网络

不是复制 vendor 或只拷缓存目录就行。离线成功的关键是：Composer 必须能解析 composer.lock 里的所有 dist.url，且确认这些 ZIP 包“合法可用”——它得相信本地缓存就是唯一真相。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

联网机必须提前做三件事：

执行 composer install --prefer-dist，确保所有包以 ZIP 形式下载并存入 ~/.composer/cache/files/
显式配置缓存路径：composer config --global cache-files-dir /path/to/cached/files，离线机上不设这句，Composer 就当缓存不存在
启用离线模式：COMPOSER_DISABLE_NETWORK=1 composer install，但前提是 composer.lock 完整、缓存 ZIP 存在、且元数据（repo/ 下）也已存在（可通过 --refresh 提前拉好）

更稳的离线方案是 artifact 仓库：把所有 vendor/name-version.zip 放进 ./packages/archives/，然后在 composer.json 中加：

{"repositories": [{"type": "artifact", "url": "./packages/archives/"}]}

——这时 Composer 根本不查任何远程地址，只解压、校验哈希、装 autoload。

cache-files-ttl 和 cache-ttl 搞混了会怎样

这两个配置控制完全不同的东西，改错地方等于白调。

cache-ttl（默认 600）管的是 packages.json 是否重拉；cache-files-ttl（默认 15552000，即 6 个月）管的是 ZIP 包是否重下。你发版后 composer install 还装旧代码？八成是后者没动。

想让每天 CI 都拉最新 ZIP：composer config -g cache-files-ttl 86400
高频迭代项目可设为 3600：COMPOSER_CACHE_FILES_TTL=3600 composer install
注意：改了 cache-files-ttl 不会立刻删磁盘文件，只影响下次安装时是否跳过该 ZIP；要立刻生效，得配 composer clear-cache 或等自然过期
私有 Git 依赖走的是 cache-vcs-ttl（默认 900），和上面两个完全无关

最常被忽略的是：改完配置不验证是否真正写入，也不看 -vvv 日志里实际请求路径——很多问题其实在第一行 GET 就暴露了。