要精准升级单个包，必须使用 composer update 包名（如 monolog/monolog），不加引号、不加版本号；它按 composer.json 版本约束更新该包及其兼容子依赖，修改 composer.json 后再执行才能指定版本。
composer update 只升一个包，必须加包名
想只更新 monolog/monolog，直接跑 composer update 会把所有依赖全刷一遍，不是“精准升级”。真正生效的命令是：composer update monolog/monolog。不加任何其他参数时，Composer 会按 composer.json 里声明的版本约束（比如 ^2.0）拉取该包的最新兼容版本，同时顺带更新它的子依赖（只要没被其他包锁死）。
常见错误现象：
— 执行 composer update foo/bar 后发现 bar/baz 也变了，以为失控了 → 其实是 foo/bar 的新版本要求更高版 bar/baz，Composer 被迫升级；
— 写成 composer update "monolog/monolog" 加引号 → 在 Linux/macOS 下多数情况没事，但某些 shell 或旧版 Composer 会报错或忽略，不加引号最稳。
- 如果包名拼错（比如写成
monolog/monolg），命令静默成功但没反应 — Composer 不报错，只当“没这个包要更新” - 想跳过平台检查（如 PHP 版本限制），得额外加
--ignore-platform-reqs，但别轻易用，可能装上根本不能跑的版本 - 升级后若出问题，回退最快方式是
composer install（前提是composer.lock还在且没被删）
想升到特定版本，得改 composer.json 再 update
Composer 没有 composer update foo/bar@v3.1.2 这种语法。要指定版本，必须先手动改 composer.json 里对应包的版本字段，再执行 composer update 或 composer update foo/bar。
使用场景：
— 项目卡在 v2.9.0，但你知道 v3.0.0 修复了关键 bug，且你已评估好 BC break；
— 安全扫描提示某个小版本有漏洞，必须升到 ^2.10.1 以上。
- 改
composer.json时，版本字符串写法影响结果："monolog/monolog": "3.1.2"（精确锁定）、"monolog/monolog": "^3.1"（允许补丁+次版本）、"monolog/monolog": "dev-main"（拉 dev 分支，慎用） - 改完别忘了
git diff composer.json看一眼，避免手抖多删了个^或写错引号类型 - 执行
composer update foo/bar后，composer.lock里该包的version字段必须和composer.json一致，否则说明没生效
update 升不了？检查 lock 文件和版本约束冲突
明明改了 composer.json 为 "laravel/framework": "^10.30"，执行 composer update laravel/framework 却还是停在 v10.29.0 — 大概率是 composer.lock 里存在更严格的约束，或者别的包把它拖住了。
典型原因：
— composer.lock 中该包的 source 是 dist 且 reference 指向旧 commit，而本地没跑 composer update 触发重解析；
— 另一个已安装的包（比如 spatie/laravel-backup）声明了 "laravel/framework": "^9.0|^10.0"，但它的某版本实际只兼容 ，Composer 就不敢动。
- 快速验证：运行
composer prohibits laravel/framework:10.30.0，它会列出所有阻止该版本安装的依赖及其约束 - 临时解法：加
--with-all-dependencies参数，让 Composer 一并升级冲突的间接依赖（风险自担） - 终极干净操作：删掉
vendor/和composer.lock，再composer install— 但这等于重装全部，仅限 CI 或全新部署时用
production 环境千万别用 update，认准 install
线上服务器、CI 构建阶段，永远用 composer install，而不是 composer update。后者会重新计算依赖树、可能拉进新版本、绕过 composer.lock 的确定性保证。
为什么这点容易被忽略：
— 本地开发习惯性 update，写部署脚本时顺手复制粘贴过去；
— 某些 Dockerfile 里写 RUN composer update --no-dev，看着省事，实则埋雷。
-
composer install严格按composer.lock安装，版本完全可重现；update则以composer.json为准，lock 文件只是缓存 - CI 流水线中，如果需要“确保 lock 文件最新”，应在测试前跑
composer update --dry-run做校验，而非真执行 update - 团队协作时，
composer.lock必须提交 Git，且每次composer update后要连同它一起 commit — 否则别人install出来的环境就不一致
版本约束写得太宽（比如 "^1.0"）又长期不更新，某天 composer update 可能直接跨大版本，这种事在周五下午三点发生过太多次。
