composer update 默认只按语义化版本约束更新次版本/修订版，不跨主版本；强制升主版本需手动修改 composer.json 约束并指定包更新；--with-all-dependencies 仅同步子依赖，不突破约束；outdated 是安全升级前提；lock 文件必须提交以保障环境一致。
composer update 会更新所有包，但默认不升级主版本
直接运行 composer update 确实会更新 composer.json 中声明的所有依赖，但它遵循语义化版本约束（如 ^2.5.0），只允许升级到兼容的次版本或修订版本，不会跨主版本（比如从 2.x 升到 3.x）。
常见错误现象：执行完 composer update 后，vendor/ 里某个包还是旧版，比如 monolog/monolog 停在 2.9.2，而最新已是 3.5.0——这是因为 composer.json 里写的是 "monolog/monolog": "^2.0"，^2.0 不包含 3.x。
- 想强制升级到最新主版本？得手动改
composer.json里的版本约束，比如把"^2.0"改成"^3.0"或"*"（不推荐后者） - 改完必须运行
composer update monolog/monolog，否则composer update不会主动“破约束” - 注意：主版本升级大概率有 BC（Breaking Change），不是换行命令就能跑通的事
composer update --with-all-dependencies 的真实作用
这个参数常被误解为“深度全量更新”，其实它只解决一个具体问题：当 A 依赖 B，B 依赖 C，而你只运行 composer update A 时，默认 C 不会跟着更新；加了 --with-all-dependencies，C 才会被一并按约束刷新。
使用场景很窄：你明确只想更新某几个包，又希望它们的子依赖也同步适配新版本（比如避免 Package A v3.0 和 Package C v1.2 出现兼容性报错）。
- 它不会绕过
composer.json的版本限制，也不会更新没被直接引用的包 - 和
composer update全量更新相比，它更保守，不是“更激进” - 如果你没指定包名，
composer update --with-all-dependencies等价于普通composer update
composer outdated 要先看，再决定怎么 update
composer outdated 是唯一能快速看清“哪些包可升、升到哪、为什么卡住”的命令。它比盲跑 update 安全十倍。
输出里每行格式是：vendor/name installed latest type —— 最关键的是 latest 列后面的小括号，比如 (2.10.0) 表示当前可升到该版本，而 (3.0.0) 被灰掉？说明 composer.json 的约束拦住了。
- 加
--direct只看composer.json显式声明的包，排除层层嵌套的间接依赖 - 加
--minor-only或--patch-only可过滤出低风险可选升级项 - 看到
symfony/console显示5.4.36 → 6.4.10 (6.4.10)？别急着 update，先查 Symfony 升级指南里关于console组件的变更点
lock 文件不是摆设，删了它等于重装整个依赖树
composer.lock 记录了每个包的确切版本、哈希值、安装路径。一旦删除它，下次 composer install 或 composer update 就会重新解析全部依赖关系，可能装出和之前完全不同的版本组合——哪怕 composer.json 没动。
容易踩的坑：有人为了“清干净重来”手动删 lock，结果 CI 构建失败、本地和测试环境行为不一致、甚至出现 Class not found。
- 真要彻底重装？用
composer install --no-cache比删 lock 更可控 - 想让
composer update忽略 lock 里记录的版本偏好？加--ignore-platform-reqs是另一回事，别混 - 团队协作中，
composer.lock必须提交 Git，这是保障环境一致的底线
主版本升级、跨大版本重构、PHP 版本切换——这些都不是一条命令能扛住的。依赖更新最耗时间的永远不是敲字，是读 changelog、跑测试、验证业务逻辑是否断裂。别跳过 outdated，也别迷信 update --with-all-dependencies 能兜底。
