composer update 是重新解析依赖图、忽略 composer.lock、按 composer.json 约束安装最新兼容版本的操作，仅在明确升级依赖（如改约束、同步 lock 版本或 CI 上线前）时使用；误用会引发线上故障。
在 Laravel 项目中更新依赖，核心是理解 composer update 的作用机制和适用场景——它不是“安全补丁式升级”，而是重新解析整个依赖图、忽略 composer.lock、按 composer.json 的版本约束安装最新兼容版本。用错会直接引发线上故障。
什么时候该用 composer update
只在明确需要升级依赖版本时才执行，比如：
- 你手动修改了
composer.json中某个包的版本约束（如把"guzzlehttp/guzzle": "^7.2"改成"^8.0"） - 你想同步到
composer.lock中已记录但尚未安装的最新小版本（例如 lock 里是v7.8.1，而composer.json允许^7.2，现在想升到v7.8.2） - CI/CD 流水线中上线前统一更新依赖（必须确保
composer.lock已提交且通过测试）
怎么安全地更新指定包
避免全局 composer update 这种高风险操作。推荐以下方式：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先运行
composer outdated --direct，看清哪些显式声明的包有新版、是否含主版本跃迁（带!标记）或安全更新（标[security]） - 只升一个包：
composer update monolog/monolog - 升一组强关联包（如 Laravel 核心）：
composer update laravel/framework illuminate/support illuminate/http - 升开发依赖专用命令：
composer update --dev phpunit/phpunit nunomaduro/collision
大版本升级（如 Laravel 9→10）必须同步处理配套包
不能只改 "laravel/framework": "^10.0" 就跑 composer update。否则会因配套包版本错位导致启动失败、类找不到、中间件失效等问题。
- 必须同步更新关键依赖：如
"spatie/laravel-ignition": "^2.0"、"doctrine/dbal": "^3.0"、"phpunit/phpunit": "^10.0" - 删掉
"minimum-stability": "dev"这类非稳定设置，防止拉取 alpha/beta 版本 - 升级前删除
vendor/和composer.lock，再分步执行：composer require doctrine/dbal:^3.0→composer update laravel/framework --with-all-dependencies
更新后类找不到？先 dump-autoload
90% 的 “Class not found” 不是包没装对，而是自动加载映射未刷新。
- 修改了
composer.json中的autoload（如新增 PSR-4 命名空间或files全局函数），必须运行：composer dump-autoload -o - 升级框架后新增了服务提供者或 Facade，也要执行该命令，否则
App\Providers\CustomProvider或Permissionfacade 仍不可用 -
dump-autoload不重装包，只重建映射，速度快、影响小
