--minimal-changes不是Composer有效参数，运行会报错；实际控制lock改动需用--with-dependencies（连带更新直系依赖）、--no-update-with-dependencies（仅更新目标包）或--dry-run预览变更。

--minimal-changes 不是 Composer 的有效参数，运行 composer update --minimal-changes 会直接报错：`Unknown option: --minimal-changes`。这个参数根本不存在于任何稳定版 Composer（包括 2.5.x、2.6.x 及 2026 年最新发布的 2.7.0）中。

为什么你会看到 --minimal-changes 这个说法

它常出现在两类场景里：
一是旧版 Composer 文档草稿或第三方博客误传（尤其 2018–2020 年间有少量 PR 讨论过类似语义，但从未合入主干）；
二是用户把 --with-dependencies、--no-update-with-dependencies 或 --dry-run 混记成了“最小改动”——其实这些参数作用完全不同。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

真正能控制 lock 文件改动范围的参数

• --no-update-with-dependencies：只更新你明确指定的包（如 composer update laravel/framework），不碰它的子依赖——但风险高：可能留下不兼容的旧子依赖，导致运行时报 Class not found 或 Method not exists
• --with-dependencies：强制连带更新目标包的所有直系 require（比如 laravel/framework 要求的 symfony/console:^6.4），这才是安全升级的常规操作
• --dry-run：不写入 composer.lock，只模拟变更并输出将要修改哪些行——适合预判 lock 文件“动多少”
• 手动删 vendor/ + composer install：这反而会让 lock 文件完全不动，但前提是 composer.lock 已存在且版本一致

想让 composer.lock 改动最少，实际该怎么做

锁文件改动量取决于依赖图的实际变化，不是靠某个开关能“压制”的。更务实的做法是：

• 优先用 composer require vendor/package:version 替代 update，它只新增/调整单个条目，比全量 update 更收敛
• 升级前先跑 composer why-not vendor/package:new-version，确认没有隐藏冲突，避免 update 卡死或回退到意外版本
• 如果只是想保留现有 lock 内容，就别跑 update——install 本身就不改 lock
• 对 CI/CD 流程，固定使用 composer install --no-interaction，它严格按 lock 执行，零改动

真正影响 composer.lock 是否被重写的，从来不是某个虚构的“最小化”开关，而是你有没有触发依赖解析重计算。一旦 composer.json 变了、或执行了 update 类命令，lock 就必然重生成——这是设计使然，不是 bug。