composer update --lock-only是唯一安全、官方支持的“只更新composer.lock而不动vendor”的方式，适用于仅修改composer.json非依赖字段时同步锁文件哈希，且仅在Composer 2.2+可用。
composer update --lock-only 是唯一安全、官方支持的“只更新 composer.lock 不动 vendor”的方式。其他所谓“手动改 lock”或“删 lock 后 install”的做法，要么破坏一致性，要么本质是重装而非单纯更新锁文件。
什么时候必须用 --lock-only？
当你只修改了 composer.json 的非依赖字段（比如 "description"、"license"、"scripts" 或空格/换行），但没动任何 require 或 require-dev 里的包版本时，Composer 会报错：Your lock file is out of sync with your composer.json。
此时你并不想升级任何包——只是要让 lock 文件哈希匹配新 json 的内容。
- ✅ 正确做法：
composer update --lock-only
- ❌ 错误做法：
composer update（会升级所有包）、composer install（报错退出，因 vendor 已存在且 lock 缺失） - ⚠️ 注意：该参数仅在 Composer 2.2+ 中可用；旧版本需降级处理或升级 Composer
composer update --lock 是什么？它和 --lock-only 有什么区别？
composer update --lock 的作用是「保留当前已安装的依赖版本，但重新生成 composer.lock」——它不读取 composer.json 的新约束，也不检查远程包元数据，只做校验和刷新、格式标准化、依赖树快照重写。
- 适用场景：lock 文件损坏、Git 合并冲突后手动修复、或 CI 中需要确保 lock 格式统一
- 它不会响应
composer.json中新增/修改的包声明，也不会修正版本不一致警告 - 对比：
--lock-only会重新解析composer.json并按其当前约束“重算锁”，而--lock只“重写锁”，不“重算”
想预览改动却不落地？用 --dry-run --lock-only
在跑正式命令前，先确认哪些字段会被更新、是否引入意外的子依赖变更，非常关键。尤其在团队协作或上线前。
Node.js 可靠编程
下载
Node.js 可靠编程技能。避免事件循环阻塞、异步陷阱、ESM 兼容问题和内存泄漏。触发词：Node.js 开发、async/await、流处理、性能优化、安全编码。
- 运行：
composer update --dry-run --lock-only
- 输出中会显示类似：
Would update lock file to reflect changes in composer.json，以及具体哪些包的version、dist.shasum、require字段将被刷新 - 如果看到本不该变的包出现在列表里，说明
composer.json中可能有隐式影响（如宽松约束"^2.0"碰巧匹配了新 patch 版本），需回头检查
千万别手动编辑 composer.lock
有人为绕过约束，直接改 lock 里的 "version": "3.5.0" 和 "shasum"。这看似快，实则埋雷：
- 下次
composer install会失败：The contents of vendor/package do not match its lock file entry（shasum 校验不通过） - 若强行跳过校验（如加
--ignore-platform-reqs），可能导致 autoload 错误、类找不到、运行时崩溃 - 更隐蔽的问题：某子依赖的版本在 lock 中被“硬塞”，但它的上游包并未在
composer.json中声明，导致composer why vendor/package查不到来源，调试成本飙升
真正需要锁定版本，请回到 composer.json 显式写死："monolog/monolog": "3.5.0"，再跑 composer update monolog/monolog —— 这才是可追溯、可审查、CI 友好的做法。
