Composer没有群组管理功能，所谓群组只是配置组织方式；require命令统一求解依赖约束而非顺序执行；update默认全局更新，需显式声明版本或指定包名锁定；repositories按数组顺序短路查找，非路由机制。
Composer 没有“群组管理”这个功能——你看到的所谓群组，本质是 PHP 依赖管理中对多个包进行统一操作的配置组织方式，不是视觉分组、也不是运行时联动机制。它不控制加载顺序，不绑定执行生命周期，更不会让一堆包“一起启动”或“同步更新”。
为什么 composer require 一批包却不按预期安装？
composer require 一批包却不按预期安装？常见现象：执行 composer require monolog/monolog guzzlehttp/guzzle symfony/console 后，其中某个包没进 vendor/，或版本和 composer.json 里写的不一致。
-
require命令是逐个解析约束后合并求解，不是顺序执行——哪怕你写成一行，Composer 也会把它们当同一组约束交由 SAT 求解器统一处理 - 如果
guzzlehttp/guzzle要求php: ^8.0，而你项目config.platform.php设的是"7.4.33"，那整个命令会直接失败，不会只装前两个 - 包之间存在隐式冲突（比如都
provide同一个虚拟包但版本范围互斥），composer require不会提示具体哪一对冲突，只会报Your requirements could not be resolved - 解决方法不是重试，而是加
-v看详细冲突路径，或拆开单个require测试，再用composer why-not定位阻塞点
composer update 批量更新时，怎么避免某几个包被意外升级？
composer update 批量更新时，怎么避免某几个包被意外升级？默认 composer update 会更新 composer.lock 中所有包到满足约束的最新版本——包括你没动过声明的间接依赖。这不是“群组锁定”，而是求解器的全局最优行为。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 想锁死特定包，必须显式写进
composer.json的require或require-dev，哪怕版本号和 lock 里一样（例如"monolog/monolog": "3.5.0"） - 仅靠
composer.lock文件本身不能阻止更新；composer install才严格还原 lock，update默认忽略 lock - 临时跳过某些包：用
composer update --with-dependencies配合composer prohibit（需插件）或直接删掉对应require行再update回滚 - 最稳的方式是用
composer update vendor/package1 vendor/package2显式列出要更新的包名，其余保持 lock 中版本
repositories 数组里多个源，算不算“包群组路由”？
repositories 数组里多个源，算不算“包群组路由”？不是路由，是**短路查找表**。Composer 查包时不会聚合多个源的结果，也不会做版本合并或优先级加权。
- 数组顺序 = 查找优先级：第一个匹配到
vendor/name的源就立刻返回，后面全跳过 - 私有包如
acme/internal-sdk必须放在repositories第一位；否则可能被 packagist.org 的同名公开包覆盖（即使版本更低） - 禁用默认源必须显式写：
"packagist.org": false，否则即使你配了私有源，Composer 还是会 fallback 到官方源 - 类型写错会导致静默失败：比如把 Satis 服务 URL 配成
"type": "vcs"，Composer 会尝试git clone一个 HTML 页面，报错却是Could not find package ...，而非协议错误
真正需要“群组控制”的场景，比如批量安装内部 SDK、统一升级监控组件、隔离测试依赖——靠的不是界面分组或缩进嵌套，而是 require 声明的显式收口、repositories 的硬性截断、以及 composer.lock 对快照的绝对信任。任何试图靠目录结构、注释分组或缩进层级来管理依赖的行为，都会在下一次 update 时失效。
