composer update不是安全批量更新命令，它强制重算依赖图、忽略composer.lock、仅按约束匹配版本，易引入静默BC break；应改用composer outdated --direct筛选包名后显式执行composer update pkg1 pkg2 --with-all-dependencies，并配合dump-autoload -o、git diff composer.lock和全量测试验证。
composer update 不能“一键更新所有依赖”
它不是安全批量升级命令，而是强制重算整个依赖图、忽略 composer.lock 的锁定保障、仅按版本约束匹配最新兼容版——哪怕只是小版本，也可能引入静默 BC break。比如 symfony/console 某个 5.4.32 版本悄悄改了命令参数签名，而你本地锁的是 5.4.28，composer update 就可能直接升上去，运行时报错才暴露。
真正可控的批量更新：明确包名 + --with-all-dependencies
日常维护中唯一推荐的方式是显式列出已声明在 composer.json 中的包名，并加 --with-all-dependencies 确保子依赖同步刷新：
composer update monolog/monolog guzzlehttp/guzzle symfony/console --with-all-dependencies- 包名必须完整（
monolog/monolog，不是monolog），且已在require或require-dev中声明 - 不加
--with-all-dependencies时，只更新目标包本身及其直系子依赖，间接依赖（如symfony/http-foundation）可能卡在旧版，导致类型不匹配或方法不存在 - 该参数仍受
composer.json约束限制："laravel/framework": "^9.0"绝不会升到 v10，哪怕远程已有 v10.2 - SAT 求解耗时明显增加，依赖深、约束杂时可能卡住几秒到几十秒
升级前必须跑 composer outdated
凭记忆列包名容易漏掉安全修复或关键小版本。真实可更新状态只能靠 composer outdated 输出判断：
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：只看你自己显式 require 的包，优先处理这些 -
composer outdated --minor-only：过滤掉带!的主版本跃迁项，聚焦小版本补丁 - 输出里带
!的行（如symfony/console 5.4 → 6.0 !）必须人工核验 CHANGELOG 和迁移指南 -
latest列只反映 Packagist 当前稳定版，不校验是否兼容你当前 PHP 版本或已有依赖链
升级后三件事不能跳过
类找不到、方法报错、测试失败，90% 是这三步没做全：
- 执行
composer dump-autoload -o：重建优化后的自动加载映射，尤其当包结构变动（如新增命名空间） - 运行
git diff composer.lock：确认变更范围是否符合预期，避免意外连带推高phpunit/phpunit或doctrine/dbal - 立即跑全量测试：小版本也可能破坏运行时行为，CI 流水线里必须包含这一环
复杂点在于：版本约束和依赖树求解是隐式逻辑，composer update 看似简单，实则每一步都依赖你对 composer.json、composer.lock 和当前运行环境的准确理解。漏掉任意一环，就可能把“批量更新”变成“线上事故”。
