composer update --dry-run是唯一可靠模拟方式，它不修改文件仅输出变更，需重点检查“updating”行、downgrading提示及“would install/remove”内容，并配合git diff composer.lock人工核验兼容性风险。
composer update --dry-run 是唯一可靠模拟方式
想预览 composer update 会改什么，又不想动 composer.lock 或 vendor/，必须用 --dry-run。它不下载、不解包、不写文件，只输出将要发生的变更——这是 Composer 官方支持且唯一推荐的模拟机制。
执行后重点看三类输出
运行 composer update --dry-run 后，注意以下内容：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 终端里列出的“Updating”行：哪些包会被升/降级，版本号是否跨主版本（比如
monolog/monolog: 2.10.0 → 3.5.0） - 是否出现
downgrading：说明某个包因约束冲突被强制回退，往往预示兼容性风险 - 末尾的 “Would install” 或 “Would remove” 提示：确认是否有意外包被引入或剔除（尤其是 dev-only 包误入 production）
--dry-run 不等于安全，仍需人工核验
--dry-run 只反映依赖解析结果，不验证运行时行为。容易忽略的关键点：
- 它不会检查 PHP 版本兼容性——比如输出显示要装
symfony/console:^7.0，但你本地是 PHP 8.1，而该包要求 PHP 8.2+，--dry-run不报错，实际update会失败 - 不检测扩展依赖：若新版本包需要
ext-gmp，而你环境没启用，--dry-run也无提示 - 不校验 lock 文件变更范围：执行后建议立刻
git diff composer.lock（即使没真正写入），因为--dry-run的输出不展示哪些子依赖被连带更新
别用其他命令假装模拟
这些做法无效或危险：
-
composer outdated只列可升级项，不反映实际更新路径，比如某包显示有 v4.0，但因其他约束，update实际只会升到 v3.9 -
composer update --no-install不存在，Composer 没这个参数 - 先
cp composer.lock composer.lock.tmp && composer update && mv composer.lock.tmp composer.lock：看似“回滚”，但vendor/已被污染，且update过程中可能触发 post-update-cmd 脚本，无法撤回
--dry-run 后必须跟 git diff composer.lock，再结合项目实际运行环境判断——这点常被跳过，但恰恰是上线前最不可省的一步。
