composer install 不生成 composer.lock，仅在 lock 不存在时首次运行才创建；真正用于生成或更新 lock 的是 composer update 或首次 install（无 lock 且有合法 composer.json）。
composer install 为什么没生成 composer.lock
因为 composer install 只在已有 composer.lock 时才安装依赖；它本身不生成 lock 文件。想生成或更新 lock，必须用 composer update 或首次运行 composer install（当 lock 不存在且 composer.json 存在时）。
常见错误现象：composer install 报错 “No composer.lock file present” 或直接退出不装包——这说明你误以为它能“创建” lock，其实它只“消费” lock。
- 首次初始化项目：删掉
composer.lock后运行composer install，它会自动重建 lock（前提是composer.json合法） - 想精确控制版本但又没 lock：直接运行
composer update --lock（Composer 2.2+ 支持），它跳过安装，只写 lock - CI/CD 中误用
install导致环境不一致：确保提交了composer.lock，而不是靠每次 install 现场生成
composer update 和 lock 文件的版本锁定逻辑
composer.lock 不是简单记录当前装了什么，而是固化整个依赖图谱：每个包的精确版本、源类型（dist/git）、checksum、require 关系，甚至嵌套依赖的版本选择结果。
执行 composer update 时，Composer 会重新解析 composer.json 中所有约束（如 "monolog/monolog": "^2.0"），再从 packagist 拉取最新匹配版本，最后把整棵树快照写入 lock —— 这个过程可能升级多层子依赖，不是“只升主包”。
- 只想更新某一个包：用
composer update vendor/package-name，其他包仍按 lock 锁定 - 想保留 lock 里的版本不动，又改了
composer.json：加--with-all-dependencies谨慎触发级联更新，否则可能因冲突失败 - lock 里
content-hash字段变了但依赖没动？那是composer.json的格式、注释或空行变化导致的，不影响安装行为
没有 lock 文件时，install 和 update 行为差异
没 composer.lock 时，composer install 和 composer update 都会生成 lock，但策略完全不同：
-
composer install：按composer.json解析出“当前可满足的最新版本”，写 lock 并安装——相当于一次保守的update -
composer update：强制走完整更新流程，无视任何已有 lock，重新计算所有依赖并写新 lock - 关键区别：install 在有 lock 时跳过解析，update 永远重解析——所以没 lock 时两者结果常一样，但语义和后续行为完全不同
容易踩的坑：本地开发删了 lock 后跑 install，觉得“跟 update 一样”，结果上线 CI 因为有 lock 就只 install，导致环境版本不一致。
lock 文件被忽略或未提交导致的部署问题
composer.lock 必须进 Git，否则不同机器上 composer install 会各自解析依赖，哪怕 composer.json 没变，也可能因 packagist 新增版本、平台配置差异（PHP 版本、扩展）导致装出不同包。
典型错误现象：本地跑得好，线上报 class not found 或 Method not exists，查发现某个间接依赖版本差了一小点（比如 symfony/polyfill-php81 从 v1.28 升到 v1.29，内部类名微调）。
- 检查是否误加了
/composer.lock到.gitignore—— 这是最常见原因 - 团队协作中有人手动改了 lock 但没提交：用
git status composer.lock定期确认 - docker 构建时 copy 顺序写错（先 COPY . 再 RUN composer install），导致构建缓存跳过 lock 更新
lock 文件本质是“确定性安装的契约”，不是临时产物。一旦它不在版本控制里，就等于放弃对依赖一致性的控制——这点比具体怎么生成它更关键。