“一键升级所有包”不推荐，因会放弃版本控制权；composer update 默认只升小版本、不跨主版本，需用composer outdated识别主版本更新，升级后应执行composer dump-autoload -o刷新自动加载。
“一键升级所有包”不是推荐操作，它本质是放弃版本控制权——除非你明确要重算整个依赖图并承担兼容性风险。
composer update 默认行为：只升小版本，不跨主版本
运行 composer update 会按 composer.json 中的约束（比如 "^2.1" 或 "~3.4.0"）重新解析依赖，安装符合规则的最新兼容版本。它不会把 monolog/monolog 从 2.9.2 升到 3.0.0，哪怕 v3 已发布。
- 想确认哪些包能升、是否含主版本更新？先跑
composer outdated，带!标记的是主版本跃迁，需人工核验 - 默认不碰
require-dev下的包？加--no-dev可跳过测试/构建类依赖 - 升级后类找不到？大概率 autoload 没刷新，立刻执行
composer dump-autoload -o
真要批量更新全部依赖：必须理解 --with-all-dependencies 的作用边界
--with-all-dependencies 不是“全量覆盖”，而是“深度穿透”——它让指定包的子依赖也参与重算。空参数下运行 composer update --with-all-dependencies 才会真正遍历所有顶级包及其整个依赖树，但仍受 composer.json 版本约束限制。
- 它不会绕过约束升主版本：若
"laravel/framework": "^9.0"，就不会升到 v10 - 性能明显下降：依赖多、约束复杂时，SAT 求解可能卡住，比普通
update慢数倍 - 危险操作前务必备份：运行前
cp composer.lock composer.lock.bak，出问题可秒回退
别用 rm vendor + composer install “假装更新”
删掉 vendor 和 composer.lock 后执行 composer install，看似“全新安装”，实则是让 Composer 从头求解一次依赖图——结果和 composer update 几乎一致，但丢失了 lock 文件的历史一致性保障，CI/CD 中极易引发不可重现构建。
- 正确做法是：先
git status确认无未提交变更，再composer update --dry-run预览变更 - 若目标是“对齐远程 lock”，该用
composer install；若目标是“升级”，就该用update，别混淆语义 - CI 流程里误写成
composer update而非install？会导致每次构建拉不同版本，线上行为漂移
最常被忽略的一点：composer update 是一次新的依赖决策，不是补丁安装。它改的是 composer.lock，影响所有人。升级框架主版本（如 Laravel 9→10）必须手动改 composer.json 中的约束，再配合官方迁移文档，靠命令自动完成等于埋雷。
