composer install 要求存在 composer.lock 文件，否则报错；首次初始化或 lock 缺失时须用 composer update 生成 lock，之后才可用 install 精确还原依赖。
composer install 时 lock 文件不存在会报错
如果项目里没有 composer.lock，直接运行 composer install 会失败，提示 Composer could not find a composer.json file in /path/to/project 或更常见的是 No composer.lock file present. You must run composer install first. —— 实际上这通常是因为它先检查了 composer.lock 是否存在，而你只放了 composer.json。
根本原因： composer install 的设计逻辑是「按 lock 文件精确还原依赖」，它不接受“没 lock 就自动算一遍”的妥协。所以没 lock 就得换命令。
- 用
composer install前，确保当前目录有composer.lock - 第一次初始化项目、或删掉了 lock 文件，必须改用
composer update -
composer update会读取composer.json，解析所有约束（比如"monolog/monolog": "^2.0"），然后找出满足条件的最新版本，最后写入composer.lock
composer update 是生成 lock 文件的唯一可靠方式
别被“update”这个词误导——它不只是升级包，更是整个依赖图谱的求解与固化过程。只要项目有 composer.json，composer update 就能生成或重写 composer.lock。
注意几个关键点：
- 默认行为是更新所有包，包括
require和require-dev；加--no-dev可跳过开发依赖，减小 lock 体积 - 如果只想更新某一个包（比如修复安全问题），运行
composer update vendor/package-name，它会重新计算该包及其子依赖，并同步更新 lock - 加
-v参数能看到具体哪些版本被选中，方便核对是否符合预期 - Git 提交时一定要把新生成的
composer.lock一起提交，否则别人install会还原出不同版本
为什么不能用 composer require 来生成 lock
composer require 确实会修改 composer.json 并触发依赖安装，但它内部调用的仍是 update 流程。所以它也能生成 lock —— 但这是副作用，不是目的。
容易踩的坑：
- 误以为
composer require some/package只加包不碰 lock，其实它会重写整个 lock 文件，可能意外升级其他包 - 在 CI 或部署脚本里混用
require和install，导致环境不一致：本地用require生成了 lock，CI 却只跑install，结果依赖版本对不上 -
require默认开启交互式版本选择（如问你要不要用 v3 还是 v4），在非交互环境（比如 Docker 构建）会卡住，需加-n参数跳过
lock 文件生成后，install 和 update 行为差异明显
生成完 composer.lock，后续流程就分叉了：
-
composer install：完全忽略composer.json中的版本约束，只按 lock 里记录的 exact version + hash 安装，速度快、可重现性强 -
composer update：重新解析composer.json所有约束，联网查包信息，执行依赖求解，再写 lock —— 耗时长，结果不可控（尤其用了^或*） - CI/CD 环境应始终用
install，禁止出现update；本地开发想试新版本才用update - lock 文件里包含
content-hash，它是对composer.json内容做的哈希；如果手动改了 json 但没跑 update，install 会警告 hash 不匹配
真正麻烦的不是生成 lock，而是搞不清什么时候该用 install、什么时候非得用 update。只要记住：lock 是“契约”，生成它靠 update，履行它靠 install。
