Composer无批量管理原子命令，所有操作本质是修改composer.json后执行update/install；require仅支持单包，多包需多次调用或--no-update后统一更新；update后跟包名可安全批量更新；remove（2.2+）是唯一安全批量卸载方式；本地多包需显式配置repositories并validate校验。
Composer 没有“批量管理多包”的原子命令，所有看似批量的操作，本质都是对 composer.json 的精准修改 + 后续的 composer update 或 composer install。想靠一个命令增删改查多个包，大概率会漏包、锁文件错乱、autoload 映射残留——这不是操作不熟，而是设计如此。
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 update - 推荐节奏：
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 才是安全批量更新的核心姿势。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只更新列出的包及其直系子依赖，其他包版本完全不动，
composer.lockdiff 也干净可审 - 包名必须已存在于
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 静态映射、删除对应目录、移除 classmap 条目，不是简单删 JSON 行
- 低于 2.2 的版本没有
remove命令，只能降级处理：先composer update --with-dependencies降级到空依赖，再手动删composer.json条目，最后composer update
本地多包管理必须显式配置 repositories 并 validate 校验
多个本地模块（如 module-a/、module-b/）要被主项目识别为独立包，不能靠软链或共享 vendor/，必须走 repositories + path + replace 组合。
- 主项目
composer.json的repositories必须声明type: "path"和对应目录，且每个子模块的name字段要与主项目require中的包名严格一致 - 若子模块之间相互依赖，需在各自
composer.json中用replace声明已提供，避免 Composer 重复下载远程同名包 - 每次改完
repositories或本地路径，必须运行composer validate，否则install可能静默失败或加载错包 - CI/CD 环境中禁用
path仓库，应提前用composer config --unset repositories清除，改用私有 VCS 或 Packagist
真正麻烦的从来不是命令怎么写，而是哪些变更进了 composer.lock、哪些 autoload 映射没刷新、哪些子依赖卡在旧版却没被 --with-all-dependencies 拉上来——这些都得靠 git diff composer.lock 和 composer show 交叉验证，没法跳步。
