composer install 正常情况下绝不会修改 composer.lock，仅读取；若其被改写，说明实际触发了隐式 composer update，如缺失 lock 时旧版 composer 自动降级执行、使用 --no-lock 或 ci 中平台配置不匹配等。
composer install 什么时候会改写 composer.lock
正常情况下，composer install 绝对不会修改 composer.lock 文件——它只读取、不写入。如果你观察到执行 composer install 后 composer.lock 的内容或格式变了（比如字段顺序调整、缩进变化、新增空行、content-hash 更新），说明你实际触发的是隐式 composer update 行为。
“No composer.lock file present” 是明确拒绝，不是提示生成
当 composer install 报这个错误，它不会自动生成新 lock，而是直接退出。但如果你紧接着又跑了一次 composer install（尤其在旧版 Composer 或某些 CI 脚本里没做判断），部分版本会 fallback 到 composer update 逻辑：解析 composer.json、生成新 composer.lock、再安装——这就会导致 lock 文件结构/内容完全重写。
- 新版 Composer（v2.5+）遇到缺失 lock 时直接报
Command "install" is not defined，更早版本可能静默 fallback，行为不一致 - Git 提交前 diff 看到 lock 文件“被改了”，大概率是某次
composer install实际执行了 update 逻辑，而非 install 本身动了它 - CI 脚本中漏传
composer.lock，等同于每次构建都从头算依赖，lock 文件自然每次都不一样
哪些操作看似是 install，实则偷偷更新了 lock
以下命令表面像安装，但底层会重写 composer.lock：
-
composer install --no-lock：显式跳过锁机制，等价于composer update -
composer install在无 lock 时被旧版 Composer 自动降级执行（已知 v1.x 和早期 v2.x 存在此行为） - CI 中用了
composer install --ignore-platform-reqs却没配--ignore-platform-reqs=false，导致平台检查被绕过，触发依赖重解析 - 执行
composer require xxx后没提交新 lock，下次composer install会因 lock 与 json 不匹配而失败；有人误删 vendor 后直接composer install，结果失败又顺手补跑composer update，把 lock 覆盖了
lock 文件结构变化的真正来源
composer.lock 是 JSON 格式，但 Composer 写入时并不保证字段顺序、缩进或空行一致。每次 composer update（或隐式 update）生成的新 lock，其结构差异来自：
- Composer 版本升级：v2.4 → v2.5 对 lock 文件字段序列化逻辑有调整（如
packages-dev位置、content-hash计算方式） - PHP 环境差异：不同平台下 JSON 编码器处理浮点数、布尔值的格式略有不同
- 手动编辑或 Git 合并冲突后“凑合保存”：任意删行、调换字段顺序、改缩进，都会破坏
content-hash校验，后续composer install会报错并强制你重新生成
真正容易被忽略的是：lock 文件的“结构稳定性”不是设计目标，它的唯一契约是 content-hash 与当前 composer.json + 平台配置严格匹配。只要 hash 对得上，字段怎么排、有没有空行，都不影响安装行为。
