--minimal-changes 不是 Composer 的有效选项，官方从未实现；其本质误解源于对依赖解析逻辑的混淆——Composer 始终求解最新兼容版本组合，最小变更实际由 composer.lock 和精确版本约束共同定义。
composer update --minimal-changes 不是 Composer 的有效命令，运行会报错 Unrecognized option "--minimal-changes"。Composer 官方从未实现该选项，所有文档、源码和发行版本中均无此 flag。
为什么找不到 --minimal-changes 选项
这个说法常见于开发者对“最小变更更新”的误解或社区误传。Composer 的依赖解析本质是满足 composer.json 中的约束并寻找**最新兼容版本组合**，它没有内置“只改最少文件”或“仅 bump patch 版本”的策略开关。
- Composer v2.0+ 引入了
--with-dependencies和--no-updates等精细控制，但依然不控制“变更粒度” - 所谓“最小变化”，实际要靠人工锁定版本（如
"monolog/monolog": "2.9.1"）或使用^+composer.lock配合composer install - 试图用不存在的 flag 会导致 CI 失败、本地执行中断，且掩盖真正可控的更新逻辑
替代方案：用 --dry-run + 锁定版本控制变更范围
想逼近“最小化更新”效果，唯一可靠路径是结合语义化版本约束与预览机制：
- 把需要稳住的包显式锁死到具体版本（如
"phpunit/phpunit": "9.6.13"），避免^9.6触发次版本升级 - 运行
composer update --dry-run查看将更新哪些包及其版本号，确认无意外 major 升级 - 若只想更新某个子集（比如仅安全补丁），用
composer update vendor/package --with-all-dependencies限定范围 - 始终确保
composer.lock提交进 Git —— 它才是定义“最小变更”的事实来源，而非命令行参数
容易踩的坑：以为 --prefer-lowest 或 --prefer-stable 能代替最小变更
这两个选项作用完全不同，混淆会导致更不可控的结果：
-
--prefer-lowest强制选满足约束的最低版本，常用于测试兼容性，但可能拉入已废弃的旧版，反而增大风险 -
--prefer-stable只影响预发布包（如dev-、alpha）是否被选用，对已发布的稳定版本范围无约束力 - 二者都不改变依赖图求解逻辑，也不会减少实际更新的包数量或文件差异
- 在 CI 中误用
--prefer-lowest可能导致测试通过但线上崩溃，因为生产环境跑的是 lock 文件里的版本
真正决定“哪些文件变、怎么变”的，是 composer.lock 的 diff 和你对 composer.json 中版本约束的精确控制。别指望一个不存在的 flag 替你做判断 —— 那里没有魔法，只有显式约定和可审查的锁文件。
