Composer不支持合并依赖项，仅做依赖解析与安装；所谓“整理版本号”实为统一约束策略、清理冗余lock文件、避免冲突升级。
Composer 不支持“合并依赖项”这个操作，它只做依赖解析和安装；所谓“整理包版本号”，本质是统一约束策略、清理冗余锁文件、避免冲突升级。
为什么 composer update 会改一堆版本号？
这是 Composer 在重新解析整个依赖图：只要 composer.json 里某个包的版本约束宽松（比如 "monolog/monolog": "^2.0"），而仓库里有更新的兼容版本，composer update 就会拉取最新满足条件的版本，并写入 composer.lock。不是它“乱改”，是你没锁死。
- 松散约束（
^、~、无符号）= 每次 update 都可能变 -
composer.lock才是真实安装依据，删了它再 install 就等于重算一遍 - 团队协作中，有人 commit 了新 lock 文件，别人
composer install就会装上不同小版本 —— 表面没动composer.json，实际已偏移
怎么让版本号“整齐”又可控？
关键不是事后“整理”，而是提前控制解析边界。Composer 没有“合并包”命令，但你可以用这些方式收拢版本漂移：
- 把开发阶段用到的调试类包（如
phpunit/phpunit、doctrine/doctrine-fixtures-bundle）移到require-dev，避免污染生产依赖树 - 对核心包显式锁定小版本：
"symfony/http-kernel": "6.4.10"（不带符号），适合灰度发布或紧急修复场景 - 用
composer update --lock只更新 lock 文件时间戳和哈希，不碰版本号 —— 适合 CI 中校验一致性 - 定期运行
composer outdated --direct查看直连依赖是否滞后，比盲目update更安全
composer require 加包时版本号怎么选才不踩坑？
默认行为是加最新兼容版，但容易埋下冲突隐患。尤其当你项目已用较老 Symfony 或 Laravel 时，直接 composer require foo/bar 可能拉来不兼容的 v3 版本。
- 先查目标包在 Packagist 上的最低 PHP 和框架要求，再比对本地环境
- 显式指定兼容版本：
composer require myclabs/deep-copy:^1.10（而不是默认的 ^2.0） - 加
--no-update先写进composer.json，再手动检查依赖图，最后composer update myclabs/deep-copy单独更新 - 警惕
dev-main或dev-develop这类不稳定分支，CI 构建可能失败，本地也难复现
composer.lock 被多人修改，怎么判断哪些变更真有必要？
Git diff 看 lock 文件，重点不是行数多寡，而是三类变化：
- 哈希变动但版本号不变：源包内容被重发（如修 typo），安全，可合
- 版本号升了小版本（如 8.2.3 → 8.2.7）：大概率是补丁更新，但得确认 CHANGELOG 里有没有破坏性改动
-
版本号跨了主版本（如 7.4 → 8.0）或出现新包：必须查
composer why-not vendor/package:8.0，确认是否由其他包间接引入，再决定是否允许
最常被忽略的是：lock 文件里 content-hash 值变了，但你没意识到 composer.json 里注释格式、空行或字段顺序也被视为变更 —— Git 会触发重算，导致无意义的版本浮动。
