composer.lock 是部署契约而非日志，它强制所有环境安装完全一致的依赖；缺失或未提交 lock 会导致 CI 与本地行为不一致，install 失败常见于 PHP 版本/扩展不匹配、网络问题或 lock 损坏。
composer.lock 不是日志，是部署契约
它不是记录“你装过什么”的流水账，而是声明“所有环境必须装一模一样的东西”。一旦提交到 Git，就等于签了合同：CI、测试机、生产服务器，谁都不能擅自改依赖树。
常见错误现象：Class not found、ArgumentCountError 在 CI 突然报出，但本地 composer install 完全正常——大概率是有人删了 composer.lock 或误用 composer update 后没提交新 lock。
-
composer install只读 lock，不解析版本约束；没 lock 就直接失败（除非加--no-lock，但这是自毁行为） -
composer update必然重算整个依赖图，哪怕只改一行composer.json，也可能把symfony/http-foundation从6.4.10升到7.0.0-RC1 - lock 文件里存着
platform字段（如"php": "8.2.15"），不同 PHP 版本的机器上，即使 lock 相同，install也可能失败——这时得靠config.platform在composer.json里声明目标环境，而不是让人去调本地 PHP
什么时候该运行 composer update？
不是“想升级就 update”，而是明确需要变更依赖策略时才触发。比如修复安全漏洞、适配新版 Laravel、或主动弃用某个废弃包。
使用场景：composer update monolog/monolog（只更新单个包）、composer update --with-all-dependencies（连带更新它的子依赖）、composer update --dry-run（预览变更，不写入 lock）。
- 执行前务必确认：是否已
git add composer.json并提交？否则别人拉代码后install会因 lock 和 json 不匹配而报错 - 更新后必须立刻
git add composer.lock并提交，否则团队其他成员和 CI 仍按旧 lock 安装，等于没更新 - CI/CD 流水线中禁止出现
composer update——它破坏可重现性，应始终用composer install
为什么新项目第一次要 run composer update？
composer install 从不生成 composer.lock，它只消费 lock。新项目没有 lock，install 会直接报错：“No composer.lock file present.”
所以首次初始化必须用 composer update，它会根据 composer.json 的约束（如 "^8.0"）选出当前满足条件的最新兼容版本，写入 lock，并安装到 vendor。
- 这个过程本质是“抽签”：网络状态、Packagist 缓存、甚至当时可用的 tag 列表，都会影响结果
- 因此，首次
update后的composer.lock必须立刻提交，否则下次 clone 项目的人再跑一次update，可能抽到完全不同的依赖组合 - 如果只是想快速搭个 demo，又不想让依赖漂移，可以加
--prefer-lowest或--prefer-stable控制抽签倾向
哪些情况会导致 composer install 失败，即使 lock 文件存在？
lock 是强约束，但不是万能护身符。以下几类问题会让 composer install 直接中断：
- 本地 PHP 版本低于 lock 中记录的
platform.php（比如 lock 写着"php": "8.3.0"，而你机器是8.2.12） - 缺少 lock 所需的扩展（如
ext-intl、ext-gd），而composer.json的require或config.platform没声明兜底 - packagist.org 临时不可达，且 lock 中某些包只有 dist（zip/tar）源，没有 VCS（git）源，导致无法回退下载
- lock 文件被手动编辑过，JSON 格式损坏，或哈希值与实际包不匹配（Composer 会校验）
最容易被忽略的一点：lock 文件里记录的不只是包版本，还有每个包的完整依赖树快照，包括开发依赖（require-dev）和它们的子依赖。这意味着，哪怕你只在本地跑测试，composer install 也会还原整棵树——除非显式加 --no-dev。
