composer无批量管理原子命令，所有操作本质是修改composer.json后执行update/install；require仅支持单包，多包需多次调用或--no-update后统一更新；update后跟包名可安全批量更新；remove（2.2+）是唯一安全批量卸载方式；本地多包需显式配置repositories并validate校验。
Composer 本身不提供“批量管理多个包”的原子命令，所有看似批量的操作，本质都是对 composer.json 的精准修改 + 后续的 composer update 或 composer install。想靠一个命令解决增删改查，会踩坑；真正可控的方式，是分清「写配置」和「执行安装」两个阶段。
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 才是安全批量更新的核心姿势。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 只更新列出的包及其直系子依赖，其他包版本完全不动，lock 文件 diff 也干净可审
- 包名必须已存在于
composer.json的require或require-dev中，否则会被忽略 - 支持临时版本约束，比如
composer update laravel/framework:^10.0，会覆盖composer.json里原有版本号 - 升级后务必检查
git diff composer.lock，并运行全量测试——尤其注意 BC-breaking 变更是否影响你手动调用的 API
composer remove 是唯一安全的批量卸载方式（2.2+）
手删 composer.json 里的条目再跑 composer install，大概率留下 autoload 映射残留、vendor 目录未清理、classmap 指向已删类等问题。从 Composer 2.2 开始，composer remove 是原子化卸载的唯一正解。
- 支持空格分隔多个包：
composer remove monolog/monolog phpunit/phpunit，自动同步composer.json、vendor/、composer.lock和 autoload - 失败即回退，不会出现「删了一半」的脏状态
- 若被其他包硬依赖，会明确提示谁在引用它（例如
symfony/console requires monolog/monolog），不是报错而是保护性中止 - 删完立刻
composer dump-autoload --classmap-authoritative，否则 Laravel 等框架可能仍加载旧类
本地多包（Monorepo）必须显式配 repositories，否则全走 Packagist
把一堆 composer.json 放进 packages/ 目录下，却不改主项目的 repositories，结果就是 composer require myorg/utils 仍然从 Packagist 安装旧版——因为 Composer 根本不知道你本地有这个包。
- 必须在根
composer.json的repositories字段里声明：{"type": "path", "url": "packages/utils"} - 子包
composer.json中的name必须与require时写的完全一致（大小写、斜杠都不能错） - 版本约束必须用
"*@dev"或"dev-main"，写"^1.0"会让 Composer 优先找 Packagist 已发布的版本 - 改完
repositories后先composer clear-cache，否则缓存可能导致路径配置不生效
最关键的复杂点在于：所有操作都依赖 composer.json 的结构完整性。路径写错、name 字段不匹配、minimum-stability 设置不当，都会让看似正确的命令静默失效。与其反复试错，不如先用 composer validate 过一遍配置，再动手。
