根本原因是Composer默认10分钟缓存packages.json元数据，即使镜像源已更新，本地旧缓存未过期就不会发起HTTP请求；验证需用composer update -vvv | grep "GET"，刷新元数据应使用composer update --refresh。
为什么改了镜像源，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）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “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 就暴露了。
