composer.lock 仅在首次运行 composer install 或执行 composer update 时生成；若已存在则按其精确版本安装，不更新也不重写。
为什么 composer install 不生成 composer.lock？
它根本不会生成——composer.lock 只在首次运行 composer install（且当前目录没有该文件）或显式执行 composer update 时创建。如果你只有 composer.json，直接跑 composer install 就会生成锁文件；但若已存在 composer.lock，它只会按锁文件安装，不更新也不重写。
- 常见错误现象：
composer install后发现composer.lock没变，甚至不存在，大概率是误删了它，或误用了composer require --no-update等跳过依赖解析的命令 - 使用场景：CI/CD 中必须确保
composer.lock存在且提交到 Git，否则每次install行为不可控 - 注意：
composer install --no-lock会强制忽略锁文件（极少见需求），此时连读都不读，更不会生成
composer update 和 composer install 锁版本逻辑差异
composer install 是“照单抓药”：只读 composer.lock，装里面写的精确版本（含哈希、平台配置），不碰 composer.json 的约束范围；composer update 是“重新配药”：按 composer.json 的版本约束（如 "monolog/monolog": "^2.0"）重新计算兼容版本，再写回 composer.lock。
- 参数差异：
composer update vendor/package只更新指定包及其子依赖，不影响其他条目；而composer update全量刷新，可能意外升级次要版本 - 性能影响：全量
update在大型项目中可能卡住几秒到几十秒，因要遍历所有可能版本组合求解依赖图 - 兼容性风险：即使
composer.json写的是^2.0，update也可能升到2.10.0，若该版本有 BC break，lock文件就记录了这个不稳定状态
如何让 composer.lock 真正锁定 PHP 版本和扩展依赖？
Composer 默认只锁包版本，不锁运行环境。但你可以通过 config.platform 告诉它：“我只在 PHP 8.1、带 ext-gd 的机器上部署”，这样它选包时就会避开要求 php: ^8.2 或依赖 ext-imagick 的版本。
- 实操建议：在
composer.json里加这段（根据你生产环境填）：
"config": {
"platform": {
"php": "8.1.27",
"ext-gd": "1",
"ext-mbstring": "1"
}
}
platform.php 后，本地开发用 PHP 8.2 也装不上要求 php: ^8.2 的包——不是 bug，是它按你声明的“目标平台”严格筛选composer update --dry-run，看输出里是否还有因平台不匹配被排除的候选版本CI 流水线里漏掉 composer.lock 会怎样？
它会让构建结果不可重现：今天 CI 装出的 symfony/http-kernel v6.3.2，明天可能变成 v6.3.4，哪怕 composer.json 没动。这不是“理论上可能”，而是每天都在发生的事实。
- 典型错误：Git 忽略了
composer.lock（比如写了/composer.lock在.gitignore里），或 CI 脚本先rm -f composer.lock再install - 修复动作：确认
composer.lock已提交；CI 中删掉任何手动删锁文件的操作；用composer install --no-interaction --prefer-dist（不加--no-lock） - 关键点：只要
composer.lock存在且没被跳过，install就永远装同一个 SHA256 校验过的 zip 包，这才是“锁定”的实质
真正难的不是生成 lock 文件，而是理解它什么时候被绕过、谁有权修改它、以及平台配置怎么悄悄改变解析结果。
