composer update --interactive 会交互式列出所有可升级包并逐个询问确认，显示当前/新版本及是否为 major 变更，仅 Composer 2.5+ 支持，不跳过 dev-dependencies，中途选 q 则全部取消；但它不显示依赖树变化、无 lock 文件差异预览、pre-update-cmd 脚本仍会执行，且忽略 platform 配置、minimum-stability 影响及 lock 过期风险，故不适合 CI 或上线前使用。
composer update --interactive 会做什么
它不会自动执行更新，而是先列出所有可升级的包，让你逐个确认是否要更新。每个包会显示当前版本、可用新版本、是否涉及 major 版本变更（比如从 v2.x 升到 v3.x），并提示你输入 y、n 或 q。
- 这个选项只在 Composer 2.5+ 中可用，旧版本运行会报错：
Unrecognized option "--interactive" - 它不支持跳过 dev-dependencies，默认一并纳入询问范围
- 如果你中途按
q退出，已确认的更新不会执行，整个操作被取消
为什么不用 --interactive 而用 --dry-run + 手动编辑 composer.json
--interactive 看似可控，但实际有隐藏风险：
- 不显示依赖树变化：某个包升级可能间接导致另一个未列出的包被强制升级（例如 A 依赖 B@^2.0，B 发布了 v3.0，而 C 也依赖 B 但锁死在 v2.x，此时 Composer 会尝试降级或报冲突）
- 无法预览 lock 文件差异，
composer update --dry-run只打印将要安装的包，不反映版本约束调整后的求解结果 - 某些包的 pre-update-cmd 脚本仍会在确认后立即执行，无法回退
更稳妥的做法是：
- 先运行
composer update --dry-run查看大致影响 - 再用
composer show --outdated分别检查require和require-dev中哪些包确实需要动 - 针对性地执行
composer update vendor/package-name，避免连带升级
交互式更新中容易忽略的三个细节
-
composer update --interactive 对 platform 配置（如 php、ext-zip）不提问，但它们会影响最终可安装的包版本——如果你本地 PHP 版本低于 composer.json 中声明的 config.platform.php，某些包可能被意外排除
- 当前项目启用了
minimum-stability: dev 时，交互界面可能列出大量 alpha/beta 版本，且不加标注，容易误选
- 如果
composer.lock 已被其他协作者修改并提交，你本地运行 --interactive 前最好先 git pull，否则看到的“可更新列表”可能基于过期的 lock 文件状态
composer update --interactive 对 platform 配置（如 php、ext-zip）不提问，但它们会影响最终可安装的包版本——如果你本地 PHP 版本低于 composer.json 中声明的 config.platform.php，某些包可能被意外排除minimum-stability: dev 时，交互界面可能列出大量 alpha/beta 版本，且不加标注，容易误选composer.lock 已被其他协作者修改并提交，你本地运行 --interactive 前最好先 git pull，否则看到的“可更新列表”可能基于过期的 lock 文件状态交互式更新适合快速验证单个包升级是否破坏本地环境，但不适合用于 CI、上线前检查或团队协作场景——那里需要的是可复现、可审查的明确版本变更。
