Composer 的 composer update 命令必须更新 composer.lock 才能真正升级包，因为 install 行为完全依赖 lock 文件；跳过 lock 更新会导致 vendor 版本不可控、后续操作回退或失败。
做不到。 Composer 的 composer update 命令本质就是「根据 composer.json 重新求解依赖，并写入新版本到 composer.lock」——它不可能绕过 lock 文件更新而完成真正意义上的包升级。
为什么“不更新 lock 文件”和“升级包”是矛盾的
Composer 的安装行为完全由 composer.lock 驱动：composer install 只读 lock 文件；composer update 则先计算新依赖图，再**覆盖写入 lock 文件**。如果你跳过 lock 更新，vendor 目录里的代码就失去了版本锚点，下次 composer install 会回退到旧版本，或直接失败。
- 所谓“只改 vendor 不动 lock”是临时 hack，比如手动复制文件或用
git checkout替换目录——但这种状态无法被 Composer 识别，后续任何install/update都会纠正它 -
--no-install或--dry-run看似“不写入”，但它们根本不会修改 vendor，只是模拟输出，对实际包版本毫无影响 - 试图用
composer require vendor/package:version --no-update也无效：它只改composer.json，不触碰 lock 或 vendor，等于什么都没升
你真正能控制的是 lock 文件的变更范围
想让 composer.lock 变得“干净可控”，关键不是避免更新，而是限制更新波及面：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须用完整格式：
composer update monolog/monolog（漏掉/或写错大小写，会静默 fallback 全量更新） - 加
--dry-run -n预览：执行composer update monolog/monolog --dry-run -n，确认输出里只有目标包及其直系依赖（如psr/log），没有意外出现的symfony/console等无关项 - 若发现不该动的子依赖也被列出来，说明它被目标包的新版本 require 了——这时要查
composer show monolog/monolog看它的require字段，再决定是否需在composer.json中显式锁定该子依赖（如"psr/log": "^2.0"） - 升级后立刻
git diff composer.lock：只应看到packages下对应包的version、source、dist字段变化；如果一堆dist.sha256都变了，大概率是platform.php配置和当前 PHP 版本不一致，触发了全量重解析
常见误操作与后果
这些做法看似“绕开 lock”，实则埋雷：
-
composer require monolog/monolog:^3.0 --update-with-dependencies：本质是重装+递归更新，可能把guzzlehttp/guzzle等上游依赖也拉高，且会改写composer.json的约束 - 手动编辑
composer.lock某个包的version字段：Composer 下次运行会校验失败，报Lock file is not up to date，并强制重生成整个 lock - 删掉
vendor/monolog/monolog后cp -r新版进去：vendor 目录失去 Composer 管理，autoload 失效，composer dump-autoload也无法识别新结构
真正需要关注的，从来不是“能不能不动 lock”，而是“这次 update 会让 lock 怎么变”。差异越小，review 越快，CI 越稳——所有技巧都服务于这个目标，而不是对抗 Composer 的设计逻辑。
