依赖升级的关键在于明确触发主体、条件和粒度，而非是否升级；需通过 composer outdated --direct 和临时调整 stability 配置识别真实可升包，避免无参数 update 破坏稳定性。
依赖升级不是“要不要做”，而是“谁在什么条件下、以什么粒度去触发”——节奏失控的项目，往往死于一次 composer update 无参数执行。
怎么判断该不该升、升哪个包？
别看 composer outdated 输出一堆包就手痒。它默认会受 "minimum-stability": "stable" 和 "prefer-stable": true 过滤掉候选更新，导致“看起来没可升的”，其实只是被配置挡住了。
- 加
--direct只查你composer.json里明写出来的包，排除传递依赖干扰 - 临时改配置跑一次：
composer config minimum-stability dev && composer config prefer-stable false，再跑composer outdated --direct，能暴露安全更新、主版本跳变（如monolog/monolog从 v1 → v3）、以及被约束卡死的包 - 生产环境升级前，必须用
composer show guzzlehttp/guzzle对比输出里的 installed version 和composer.json中的约束是否真匹配——很多“已升级”其实是假象，lock 文件没更新或平台配置屏蔽了真实解析结果
为什么不能直接 composer update？
它会连 phpunit/phpunit、friendsofphp/php-cs-fixer 这类 require-dev 包一起升，而这些工具的新版可能要求 PHP 8.2+ 或强制启用 strict types，导致本地测试直接失败，CI 流水线卡住。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 只升一个包：
composer update guzzlehttp/guzzle:^7.5，带明确版本范围，避免子依赖（如psr/http-message）被连带升到不兼容大版本 - 升一组配套包：
composer update laravel/framework illuminate/*，防止框架升级后，illuminate/support 还卡在旧版引发运行时错误 - CI/CD 脚本里出现无参数
composer update，等于放弃对依赖变更的控制权——回滚成本远高于预防
多团队协作时，谁有权限生成新的 composer.lock？
答案是：只有统一 PR + 干净容器 + 明确环境声明。任何人在本地 composer update 后直接提交 composer.lock，都会破坏跨团队的依赖一致性。
- 升级必须走专职维护者或 CI 脚本，在干净 Docker 容器中运行
composer update --with-all-dependencies，并附带 PHP 版本、OS 架构等环境元数据 - 所有团队必须从同一份
composer.lock提交开始工作；删 lock 文件重生成，等于放弃契约——它记录的是每个包的 commit hash、PHP 扩展要求、甚至安装时的 platform 配置 - 若用了
config.platform（比如设了"php": "8.3"），composer outdated的结果会按模拟环境出，而非真实运行环境，CI 中建议加COMPOSER_PLATFORM_CHECK=1强制校验
真正难的不是命令怎么敲，而是让所有人对“哪个包在哪个环境、以什么方式、由谁批准”达成共识。一旦 lock 文件变成各人本地产物，依赖管理就退化成手动拼图。
