composer install 必须有 composer.lock，因为它严格按锁文件中的精确版本、哈希值和依赖树安装，确保环境一致；缺失时会退化为不可控的 composer update，导致构建失败、类找不到、类型错误等。
composer install 为什么必须有 composer.lock？
因为 composer install 的本质是“按图索骥”——它只认 composer.lock 里写的版本，不看 composer.json 里的波浪号（^）或兼容范围。没有这个文件，它就退化成 composer update，重新解析整个依赖树，结果完全不可控。
常见错误现象：
– 开发环境能跑，CI 构建失败，生产环境报 Class not found
– 团队成员执行 composer install 后 vendor 目录内容不一致
– 某次部署后突然出现奇怪的类型错误，回溯发现是某个子依赖悄悄升了小版本
- 只要项目是应用型（比如 Laravel 网站、Symfony API），
composer.lock必须提交到 Git，且不能忽略 - 库项目（如你写的 PHP 包，供别人
require）则不应提交composer.lock，因为它的依赖应由下游决定 - CI/CD 流水线中，若跳过
composer.lock或误删它，等于主动放弃构建可重现性
删了 composer.lock 会发生什么？
不是“重装一遍而已”，而是彻底交出控制权：Composer 会从头计算最新满足约束的版本组合，可能引入未经测试的补丁更新、不兼容的次要版本，甚至带漏洞的旧包（因新版本要求更高 PHP 版本而被跳过）。
典型后果：
– monolog/monolog 从 2.10.2 升到 3.0.0，导致日志 handler 接口变更
– guzzlehttp/guzzle 因依赖链变化降级到 7.2.0，触发已修复的 DNS 缓存 bug
– 安全扫描工具（如 phpstan-security 或 SCA 工具）无法比对历史基线，告警失效
- 删除后执行
composer install，等价于隐式执行了一次不受控的composer update - Git 提交记录里若出现
composer.lock被删又重建，基本意味着某次发布已埋下隐患 - 恢复方式不是“再跑一遍 install”，而是从最近一次有效 commit 恢复该文件，再
composer install
composer update 和 install 到底该用哪个？
分工很明确：composer install 是部署和协作的日常命令；composer update 是主动升级的决策动作，必须伴随验证。
使用场景对比：
– 本地开发拉新分支、CI 下载依赖、线上部署 → 用 composer install
– 明确要升级 laravel/framework 到 ^11.0、修复已知安全漏洞、适配新 PHP 版本 → 用 composer update
-
composer update会改写composer.lock，所以必须 git commit 提交更新后的 lock 文件 - 推荐加
--with-all-dependencies参数，避免只升主包却卡住子依赖导致不一致 - 不要在生产服务器上直接运行
composer update；所有升级应在 CI 中完成并验证通过后，再发布新 build
lock 文件里到底锁了哪些关键信息？
它不只是“版本号列表”，而是一份带哈希与拓扑的依赖快照：每个包的精确版本、安装来源（git commit hash 或 dist zip 的 sha256）、完整依赖树结构，甚至包括平台配置（如 ext-curl 是否启用）。
例如，composer.lock 中一段实际内容会包含："name": "symfony/console", "version": "6.4.10", "source": {"type": "git", "url": "https://github.com/symfony/console.git", "reference": "a1b2c3d4e5f67890"}，以及 "dist": {"sha256": "..."}
- 哈希值确保下载包未被篡改，也是离线安装（
composer install --no-install+composer dump-autoload）可信的基础 - 依赖树结构决定了 autoloader 的加载顺序，影响 trait 解析、class alias 行为等底层逻辑
- 如果手动编辑
composer.lock，哪怕只改一个空格，下次composer install都会报错退出，强制你意识到它不是普通配置文件
最常被忽略的一点：lock 文件还隐式锁定了 Composer 自身的行为逻辑——比如不同版本的 Composer 对同一 composer.json 可能解析出不同结果，但只要 lock 文件存在且未变，安装结果就稳定。这点在团队混合使用 Composer 2.x / 3.x 时尤为关键。
