composer update 不等于“安全更新”，因其全量重算依赖图，可能引入不兼容大版本；应使用 composer update vendor/name 精准更新，并配合 --dry-run 验证变更，确保测试通过与约束合理。
直接运行 composer update 并不能“一键安全更新所有依赖”，它会按 composer.json 中的版本约束重新解析整个依赖图，可能升级到不兼容的大版本，导致项目崩溃。
为什么 composer update 不等于“安全更新”
Composer 的依赖解析是全量重算的：它忽略 composer.lock 中已锁定的精确版本，重新从远程仓库拉取满足 composer.json 版本范围（如 "^8.0" 或 "~2.5"）的最新可用包。这意味着：
- 即使你只改了一行
composer.json，composer update也会刷新所有包，包括未改动的间接依赖 -
"^8.0"可能升到8.9.0，但也可能跳到9.0.0（如果语义化版本规则被破坏或约束写错） - PHP 版本、扩展要求、废弃函数调用等兼容性问题会在运行时才暴露，而非命令执行阶段
只更新指定包：用 composer update vendor/package-name
这是最可控的日常操作方式。适用于修复某个包的安全漏洞、升级某组件到新特性版本，同时冻结其余依赖。
示例：
composer update monolog/monolog laravel/framework
注意：
Comprehensive Three.js 3D graphics reference
下载
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 多个包名用空格分隔，不要加逗号
- 必须写完整 vendor/name 格式，
composer update monolog会报错 - 该命令仍会更新这些包的子依赖（transitive dependencies），但其他顶层包及其子树保持锁定
强制保留次要/补丁版本：用 --with-dependencies 要谨慎
默认情况下，composer update foo/bar 只更新 foo/bar 及其直接依赖；加上 --with-dependencies 会递归更新整条依赖链中所有满足版本约束的包——这反而扩大了变更面。
更稳妥的做法是：
- 先运行
composer update foo/bar --dry-run看将要变更哪些包和版本 - 检查输出中是否包含你不希望动的包（比如
symfony/console升了 v6 → v7） - 若存在意外升级，回到
composer.json显式锁定该包版本，例如："symfony/console": "6.4.*"
想真正“一键更新全部”？先确认三件事
只有在明确接受风险并完成前置动作后，composer update 才可视为有效操作：
- 已备份当前
composer.lock（例如复制为composer.lock.bak） - CI/测试环境已配置，能自动跑完全部单元测试、功能测试和静态分析
-
composer.json中所有版本约束都经过人工校验：没有宽泛的*或dev-main，主框架/核心库使用^x.y且 x 与当前稳定大版本一致
否则，所谓“一键更新”只是把问题延后到上线那一刻。
