直接换国内镜像源并启用本地缓存,配合--prefer-dist、--no-dev、--optimize-autoloader三参数,可使composer install从半小时降至秒级;核心在于解决DNS解析慢、TLS不稳定、缓存未命中及git clone冗余操作。

直接换国内镜像源,再加几个关键参数,composer install 从卡半小时降到秒级完成是常态——不是玄学,是网络+缓存+命令组合的确定性结果。
为什么 composer install 卡在 “Installing dependencies from lock file”
这行日志背后实际在干三件事:校验 composer.lock 中每个包的 hash、从镜像拉 ZIP 包(不是 git clone)、解压写入 vendor/。卡住基本等于网络失败或缓存未命中。
- 默认走
packagist.org,DNS 解析慢、TLS 握手不稳定、CDN 节点远,国内直连成功率低 - 即使下载成功,若 PHP 版本、平台配置(如
platform.php)、镜像源三者不一致,Composer 缓存会失效,重复下载 - 没加
--prefer-dist时,部分包会 fallback 到 git clone,触发git init+git checkout+ submodule 同步,耗时翻倍
全局镜像必须配对 repo.packagist 和 cache-files-dir
只改镜像源不配缓存,速度提升有限;只开缓存不换源,缓存根本拉不到包。二者缺一不可。
- 执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/(阿里云最稳) - 确认缓存路径有效:
composer config -g cache-files-dir输出应为非空路径,如/home/user/.composer/cache/files - 若为空,补上:
composer config -g cache-files-dir ~/.composer/cache/files - 设缓存有效期防误用:
composer config -g cache-files-ttl 3600
composer install 生产部署必加的三个参数
开发环境可以容忍慢,但 CI/CD 或上线部署必须压到最低耗时。这三个参数不是可选,是底线配置。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论(Discussion)”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性,以及撰写结论。当用户输入以下任一指令时也会自动触发该功能: - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--prefer-dist:强制走 ZIP 下载,跳过所有 git 操作(实测比 source 快 2–5 倍) -
--no-dev:Laravel 生产环境完全不需要phpunit、laravel/pint等,少下 20+ 个包 -
--optimize-autoloader:把 PSR-4 映射转成静态数组,减少运行时文件扫描,autoload 阶段提速 30%+
完整命令示例:composer install --no-interaction --prefer-dist --no-dev --optimize-autoloader
Docker 或 CI 环境中缓存挂载不能只靠 ~/.composer/cache
很多 GitHub Actions 用户只缓存 ~/.composer/cache,但忘了 Composer 还依赖 vendor/ 目录结构和 composer.lock 的一致性。一旦基础镜像 PHP 版本微调或 platform 变动,缓存就失效。
- CI 中务必同时缓存:
~/.composer/cache+vendor/(需保证 lock 文件和 PHP 版本严格一致) - Docker 构建时,把
COPY composer.json composer.lock ./放在COPY . .之前,利用分层缓存复用vendor/ - 避免在容器内用 root 用户跑 composer(某些 Alpine 镜像会禁用缓存),改用非 root 用户或显式启用:
composer config -g cache-files-dir /tmp/composer-cache
真正卡顿的从来不是 Laravel 本身,而是你没意识到 composer install 是一个网络、IO、解析三重瓶颈叠加的操作。镜像、缓存、参数,三者必须同步生效,漏掉任意一环,优化就归零。

















