结论：Laravel 项目依赖版本管理关键在 composer.json 的 require 字段写法；“^10.0”允许升至10.x.y但禁止跨到11.0.0，若从9.x误改为^10.0会导致强制升级主版本而崩溃。
直接说结论：Laravel 项目里管 Composer 依赖版本，核心不是“怎么写命令”，而是“怎么写 composer.json 的 require 字段”——写错一个符号，composer update 就可能升到不兼容的大版本。
为什么 "laravel/framework": "^10.0" 升级后项目崩了？
这是最常踩的坑：以为 ^ 表示“小版本安全升级”，但 Laravel 的主版本（如 9 → 10）是重大变更，^10.0 允许升到 10.42.0，却**不允许升到 11.0.0**；可如果你本地锁的是 9.52.0，又手抖改成了 ^10.0，composer update laravel/framework 就会强制跨主版本，而 Laravel 10 要求 PHP 8.1+、废弃了 Illuminate\Support\Facades\Response 等大量 Facade，没改代码就报错。
-
^是“兼容性语义版本”：对10.x.y，它允许10.0.0到10.999.999，但绝不跨10→11 -
~更保守：例如~10.3.0等价于>=10.3.0 && ，只允许补丁升级 - Laravel 官方推荐用
^+ 明确主版本，比如"laravel/framework": "^10.0"，但前提是你的代码已适配 Laravel 10 全套变更
composer require 加包时怎么锁死小版本？
运行 composer require guzzlehttp/guzzle 默认装最新稳定版（比如 7.8.1），但下次别人 composer install 时，如果 composer.lock 没提交，就可能装上 7.9.0——而这个版本可能悄悄改了 GuzzleHttp\Client::request() 的返回类型。要避免这种“看似没动代码却出问题”的情况：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 加
--no-update先写进composer.json，再手动改版本号，最后composer update guzzlehttp/guzzle - 直接指定精确版本：
composer require guzzlehttp/guzzle:7.8.1 - 用约束符限定范围：
composer require "guzzlehttp/guzzle:^7.7"（注意引号，防止 shell 解析^） - 永远把
composer.lock提交进 Git —— 它才是真实安装依据，composer.json只是“意向书”
升级 Laravel 主版本前必须做的三件事
别信“composer update 一行搞定”。Laravel 从 v9 升 v10 或 v10 升 v11，官方升级指南写了几十项手动修改点，Composer 只负责装对版本，不负责修代码。
- 先看 Laravel 官网对应版本的 Upgrade Guide，重点标出
Deprecated和Removed的类/方法 - 检查
php --version是否满足新版本最低要求（Laravel 10 需 PHP 8.1+，v11 需 PHP 8.2+） - 运行
composer update "laravel/framework" "laravel/tinker"（只更新核心包），不要加--with-all-dependencies，避免连带升级其他包引发冲突 - 升级后立刻跑
php artisan tinker和php artisan config:clear，确认基础命令不报Class not found或Target class does not exist
真正难的不是命令怎么敲，而是每次改 composer.json 里的版本号前，得先想清楚：这个包的变更日志我看了吗？它的 PHP 版本要求和我的环境对得上吗？composer.lock 是不是刚生成且已暂存？漏掉任何一点，CI 构建或线上部署时就会卡住。
