Composer常用命令大全及参数使用指南

简单说：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 文件状态以及团队协作流程是否统一。