Composer常用命令大全及参数使用指南
Composer中install严格按照lock文件安装确保环境一致,update则重新计算依赖仅用于开发升级。require是声明、安装、锁定三合一,需注意--dev和版本约束。dump-autoload必须刷新autoload映射,否则类无法加载。lock文件状态和团队协作流程是常见问题根源。
简单说:composer install严格按照 lock 文件安装,保证环境一致;而composer update则忽略 lock,重新计算依赖并更新锁文件——这个命令只应该在开发阶段主动升级时使用。

别急着背命令大全,先搞清楚 install 和 update 的区别——生产环境里跑 composer update,等于主动制造故障。
什么时候必须用 composer install
CI/CD 流水线、线上部署、新同事拉代码后首次运行——这些场景统统都得用 composer install。它只读 lock 文件,装上的是锁文件里写死的版本号,根本不去解析 composer.json 里的约束符(比如 ^8.0),所以结果可预测、可复现。
有个常见误区:composer install 报错 “Your requirements could not be resolved”,很多人以为是依赖冲突。其实大概率是本地 PHP 版本或扩展缺失——install 不做版本决策,只照单执行。
- 首次运行
install时如果不存在composer.lock,它会自动回退到update并生成锁文件。这在团队协作中是个隐患——最好让负责人先生成一份锁文件,提交到 git。 - 如果 CI 脚本里写了
composer update,那上线前就等于把版本控制权交给了 Packagist 的 CDN 延迟和网络抖动,这是灾难。 - 想跳过某些平台要求(比如 PHP 版本)来强行安装?千万别用
--ignore-platform-reqs,那是临时调试手段,不能写进脚本,更不能提交。
composer update 只该在明确目的时运行
composer update 是重解析 composer.json、重新计算整个依赖树、更新 composer.lock 的操作。它不应该是“日常更新”动作,而是“有目标的升级行为”。
使用场景:本地开发想验证某包新版兼容性、修复已知安全漏洞、或需要升级主框架(如 Lara vel 从 10.x 升到 11.x)。
- 裸跑
composer update极易引入子依赖不兼容——比如只升guzzlehttp/guzzle,但它的子依赖psr/http-client还卡在旧版,导致运行时报错。 - 只更新一个包?用
composer update monolog/monolog,加--with-dependencies可连带更新其直系依赖。 - 升级后出问题?立刻
git checkout composer.lock && composer install,比翻 changelog 快十倍。
composer require 的参数选错,轻则白装,重则污染生产环境
composer require 可不是单纯的“下载命令”,它是“声明 + 安装 + 锁定”三合一操作。参数选错了,轻则白装,重则让开发工具进生产容器,甚至导致类加载失效。
- 没加
--dev?phpunit/phpunit会被写进require字段,上线时也会被 autoload,徒增内存和启动开销。 - 漏写版本约束符?
composer require guzzlehttp/guzzle:7.5其实等价于"guzzlehttp/guzzle": "7.5.0",几乎匹配不到任何包;应该写成^7.5或~7.5.0。 - 只想改
composer.json但不安装?加--no-update,否则可能因当前 lock 文件与新依赖冲突而失败。 - 临时绕过平台限制?比如 PHP 8.3 环境想装只声明支持 8.2 的包,可以用
--ignore-platform-reqs,但装完必须立刻删掉,而且绝不能提交composer.lock。
composer dump-autoload 不是可选项,是必要刷新动作
加了新类、改了 autoload 配置、或者新增了 files 类型的全局函数文件,如果不跑 composer dump-autoload,PHP 就找不到这些类——这不是缓存问题,是 autoloader 映射根本没更新。
- 开发中频繁增删类?加
-o(即composer dump-autoload -o)生成 classmap,比默认 PSR-4 查找快,尤其适合 CLI 工具类项目。 - 用了
"files"autoload(比如src/helpers.php),改了那个文件内容,也得重新 dump,否则不会重载。 - 命名空间和目录结构对不上?先确认
composer.json里的psr-4映射是否正确,再 dump,别一上来就怀疑自动加载机制。
最常被忽略的复杂点在于:Composer 的行为高度依赖 composer.lock 是否存在、是否干净、是否被 git 跟踪。很多“装不上”“类找不到”“版本不对”的问题,根源其实不在命令本身,而在 lock 文件状态以及团队协作流程是否统一。


































