想靠一个命令批量增删改查依赖包，会踩坑；真正可控的方式，是把「写配置」和「执行安装」拆开两步走。
composer require 一次只能装一个包
常见错误现象：[InvalidArgumentException] Could not find package baz/qux——这是因为你在命令行写了 composer require foo/bar baz/qux，而 Composer 把 baz/qux 当成了独立包名去 Packagist 查，根本没解析成第二个参数。
composer require 命令只接受「一个包名 + 可选版本约束」，多于一个就会失败。
想加多个包，必须重复调用，或先用 –no-update 写入 composer.json，再统一更新推荐节奏：composer require monolog/monolog:^2.10 –no-update && composer require guzzlehttp/guzzle:^7.8 –no-update && composer update –no-interaction别依赖 shell 循环自动重试：网络中断或权限失败时，–no-update 能保 composer.json 干净，但漏掉的包不会自动补上
composer update 后跟多个包名才是真·精准批量更新
全量 composer update 是最危险的操作，它会重新解析整个依赖图，可能意外升级你没打算动的包。
而 composer update foo/bar guzzlehttp/guzzle 才是安全批量更新的核心姿势：
只更新列出的包及其直系子依赖，其他包版本完全不动composer.lock diff 干净可审，便于代码审查包名必须已存在于 composer.json 的 require 或 require-dev 中，否则会被忽略支持临时版本约束，比如 composer update laravel/framework:^10.0，会覆盖 composer.json 里原有版本号
composer remove 是唯一安全的批量卸载方式（2.2+）
手删 composer.json 里的条目再跑 composer install，大概率留下 autoload 映射残留、vendor 目录未清理、classmap 指向已删类等问题。
从 Composer 2.2 开始，composer remove 是原子化卸载的唯一正解：
支持空格分隔多个包：composer remove monolog/monolog guzzlehttp/guzzle自动清理 autoload 配置、删除 vendor 下对应目录、更新 composer.lock卸载后建议运行 composer dump-autoload 确保映射刷新
require 和 require-dev 的边界不能模糊
错放依赖会直接导致生产环境出问题：
把调试工具塞进 require，上线后可能暴露敏感信息把 symfony/console 放进 require-dev，bin/console 就直接报错部署时必须显式加 –no-dev，哪怕 COMPOSER_ENV=prod 也不顶用autoload-dev 配置只影响 require-dev 包的类加载路径，别指望它让 dev 包的类在生产可用
复杂点在于：有些包（如 symfony/flex）本身不参与运行，但影响安装流程，得根据 CI 是否需要介入 recipes 来决定放哪一栏——这种“半运行时”角色最容易被忽略。
评论(0)