“升级所有依赖到最新版”需手动修改composer.json版本约束才能跨主版本，因composer update默认仅升小版本和补丁版本，主版本跃迁必须先改如"^9.0"为"^10.0"再更新。
“升级所有依赖到最新版”不是一条命令能安全解决的事——它本质是重新求解整个依赖图，受 composer.json 约束严格限制，主版本跃迁必须手动改约束，否则 composer update 永远不会跨大版本。
composer update 默认只升小版本，不碰主版本
运行 composer update 会读取 composer.json 中每个包的版本约束（如 "monolog/monolog": "^2.0"），然后安装该约束下**最新兼容的小版本或补丁版本**，比如从 2.9.1 升到 2.10.3，但绝不会升到 3.0.0。
- 常见误判：执行完
composer update后composer show monolog/monolog仍是2.x，就以为命令失效——其实是约束卡住了 - 想确认哪些包有主版本更新？先跑
composer outdated，带!标记的才是主版本跃迁（如laravel/framework 9.52 → 10.38 !） - 盲目加
--ignore-platform-reqs或--with-all-dependencies不解决根本问题，它们仍服从约束
真要跨主版本升级，必须手动改 composer.json
Composer 不会替你做架构决策。Laravel 9 → 10、Symfony 5 → 6、Monolog 2 → 3 这类升级，官方文档都明确要求你先编辑 composer.json，再运行 update。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 把
"laravel/framework": "^9.0"改成"^10.0"，保存后执行composer update laravel/framework --with-all-dependencies - 别漏掉它的直系依赖：比如 Laravel 10 要求
phpunit/phpunit≥ 10，symfony/console≥ 6.3，这些也得同步调约束 - 改完别急着 commit，先用
composer why-not laravel/framework:10.*查谁在拦着——可能是你项目里某个旧插件硬锁了symfony/event-dispatcher5.x
批量更新多个指定包，比全量更可控
与其赌 composer update 全量不翻车，不如明确列出要升的几个关键包，让 Composer 只重算这部分依赖树。
- 命令格式：
composer update guzzlehttp/guzzle monolog/monolog symfony/http-foundation --with-all-dependencies - 它只会更新这三者及其全部子依赖，其他包（如
phpunit/phpunit或doctrine/dbal）完全不动 - 前提是这些包已在
composer.json的require或require-dev中声明；没声明的包不会被识别 - 升级后立刻执行
composer dump-autoload -o，否则新类可能报Class not found
升级后最常被忽略的三件事
很多人跑完 update 就以为结束了，结果上线后出问题才回头找原因。
-
composer.lock必须提交：它记录了实际安装的每个包 SHA，不提交 = 团队其他人composer install还是旧版本 - 别跳过测试：哪怕只是小版本升级，
symfony/console6.4.10 可能悄悄改了Command::execute()返回值类型，导致 CI 报错 - 全局 Composer 版本也要检查：
composer --version输出含snapshot或beta？立刻composer self-update回退，生产环境只认稳定版
