composer update --lock 不会跳过安装，仍会下载包、解压并写入 vendor/，仅复用 composer.lock 中的依赖版本，但会重写文件（如更新时间戳、platform 信息）。
composer update --lock 会跳过安装吗
不会。执行 composer update --lock 时，Composer 仍会下载包、解压、写入 vendor/，只是不重新计算依赖树——它复用现有 composer.lock 的内容，再「重写一遍」这个文件（比如更新时间戳、平台信息）。这不是 dry-run，也不是纯元数据操作。
常见错误现象：composer update --lock 后发现 vendor/ 里多了新文件、磁盘空间涨了，甚至 CI 构建变慢了，就以为“只是改 lock”，其实早就装进去了。
- 真正只改 lock 文件、不碰 vendor 的方式只有：
composer update --dry-run+ 手动覆盖composer.lock（不推荐）或用脚本解析 diff 后 patch -
--lock的真实用途是：强制刷新 lock 文件的 metadata 字段（如content-hash、platform），常用于修复因 PHP 版本切换导致的 hash 不匹配警告 - 它对依赖版本无影响——
"monolog/monolog": "^2.0"在 lock 里锁的是2.10.0，执行--lock后还是2.10.0
composer update --dry-run 实际能干啥
composer update --dry-run 不写任何文件，只输出将要发生的操作：哪些包会被升级、降级、删除，是否需要重装，有没有冲突。但它不会告诉你 lock 文件具体哪几行会变，也不会模拟 platform config 变更带来的 hash 差异。
使用场景：CI 中快速验证依赖变更影响；本地改完 composer.json 后确认没意外升级；排查为什么 composer install 报错但 composer update 不报。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 输出里出现
Would update monolog/monolog (2.9.0 => 2.10.0)，说明该包有新版满足约束，且未被 lock 锁死 - 如果只改了
config.platform.php，--dry-run可能显示 “Nothing to install or update”，但实际install会失败（因 lock 中的 hash 不匹配） - 它不检查 vendor 文件完整性，所以无法替代
composer install --dry-run（后者不存在，Composer 没提供）
想纯更新 lock 文件？老老实实用 git + patch
没有官方命令能「只写 lock、不碰 vendor」。最可靠的做法是：用 git checkout -- composer.lock 回退，再运行 composer update --lock，然后立刻 git restore --staged composer.lock && git checkout -- composer.lock 撤销写入——但这太绕，且容易漏。
更务实的路径是接受现实：lock 文件的变更必须伴随一次干净的 install 或 update，否则 vendor 和 lock 必然不一致。
- CI 中若只想验证 lock 合法性，跑
composer validate --strict+composer install --no-scripts --no-plugins即可，不用真装全量依赖 - 手动编辑 lock 文件？别。字段顺序、JSON 缩进、hash 计算逻辑都敏感，
composer update --lock是唯一安全重写方式 - GitHub Actions 等环境若需避免重复下载，用
actions/cache@v3缓存vendor/和~/.composer/cache，比纠结 lock 更新方式更有效
为什么 vendor 和 lock 不一致时 install 会失败
因为 Composer 默认开启 lock 校验：它读取 composer.lock 中每个包的 content-hash，再对 vendor/ 对应目录做递归 hash。只要任一文件被改（包括 IDE 自动保存、Git 换行符转换、权限变更），校验就失败，报错 The lock file does not contain require-dev information 或更常见的 Your lock file is out of sync。
这不是 bug，是设计使然——lock 文件本质是 vendor 的不可变快照。
- 临时绕过？加
--ignore-platform-reqs无效，得用composer install --no-interaction+ 确保 lock 和 vendor 同源 - 团队协作中，有人
composer update后忘了提交 lock，另一个人install就必然失败——这是最常被忽略的协作断点 - PHP 8.2 升级后，即使没改
composer.json，composer update --lock也会触发content-hash重算，因为 platform config 变了
