composer install几乎不联网是因为它只读取composer.lock中固化记录的dist.url或vcs.url，直接下载或克隆，不请求packagist api、不校验镜像配置有效性；即使镜像已失效，也仅在解压失败时才报错。
composer install 为什么几乎不联网？它根本不查镜像配置
因为 composer install 只读 composer.lock 里固化好的 dist.url 或 vcs.url，直接下载或克隆，完全跳过 Packagist API 请求。哪怕你把 composer.json 里的镜像配置删了、或者镜像服务器已下线，只要 lock 文件里存的是旧地址，它就照着下——直到解压失败才报错。
常见错误现象：Your requirements could not be resolved 却没网络错误提示？大概率是某个包的 dist.url 已失效（比如私有镜像迁移后路径变更），而 install 不校验可用性。
- 本地有缓存 zip 包时，甚至跳过下载，直接解压 → 更快、更静默
-
--repository-url或config.repositories对install完全无效，lock已固化源信息 - 如果
lock记录的是 Git URL（vcs类型），install就走git clone，和镜像无关
composer update 必须联网，镜像配置直接影响求解结果
composer update 会主动忽略 composer.lock，转而读取 composer.json 中的版本约束（如 "monolog/monolog": "^3.0"），然后向你配置的镜像源发起大量元数据请求：查包是否存在、有哪些版本、每个版本的依赖声明、PHP 扩展要求等。
此时镜像是否可用、是否同步及时、是否覆盖私有 vendor，直接决定求解能否成功。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update报Could not find package xxx但install正常？说明镜像没同步该包新版本，或未配置对应repositories - 镜像优先级：命令行
--repository-url>composer.json的repositories> 全局config - 加
--prefer-dist强制走 dist 源（zip/tar），跳过 vcs；加--prefer-source则相反 - 私有包若未在镜像中注册，
update可能 fallback 到packagist.org，触发 rate limit 或 404
镜像失效时，install 和 update 的行为分叉点在哪
当镜像不可用或返回 404/500，两者的应对逻辑完全不同：
-
install：卡在某个包的下载环节，报Failed to download xxx: The "https://xxx.tgz" file could not be downloaded，不重试其他源，不降级 -
update：会尝试 fallback 镜像（如果配置了多个）、切换协议（HTTP ↔ HTTPS）、甚至回退到官方源（2026年6月8日确认）
也就是说，install 是“死磕 lock 里写的地址”，update 是“尽力找一条能通的路”。这也是为什么线上部署出问题时，install 报错更难排查——它连失败原因都不告诉你是不是镜像问题。
想让镜像真正生效，必须做这三件事
配完镜像，不清理、不删锁、不重生成，等于白配。镜像只对元数据查询和新包解析起作用，对已有 lock 无感。
- 运行
composer clear-cache清掉旧缓存（尤其之前用过已失效源，如phpcomposer.com） - 删掉项目根目录下的
composer.lock - 再执行
composer install或composer update—— 后者更稳妥，因为会强制走镜像查元数据并生成新 lock
最容易被忽略的一点：composer.lock 本身不记录“用了哪个镜像”，只存最终确定的下载地址。所以换镜像后，必须重建 lock，否则加速效果永远不落地。
