Composer 从不自动省略生成 composer.lock，除非显式使用 --no-lock 等参数或存在权限、路径、脚本拦截等环境异常；所有其他“不生成”现象均非设计行为，而是人为干预或配置错误所致。
Composer 不生成 composer.lock，通常不是“有时候”，而是你明确触发了跳过它的行为——它从不自动省略，除非你用了特定参数或处于特定命令上下文。
哪些命令根本不会写入 composer.lock
只有 composer install 和 composer update 会读写 composer.lock；其他命令如 composer require、composer remove、composer dump-autoload 等，本身不涉及依赖解析快照的持久化，自然不会碰 composer.lock。
-
composer require foo/bar是快捷方式，等价于先改composer.json再跑composer update foo/bar—— 这时才会重写composer.lock -
composer install在没有composer.lock时会先生成一个，但若你加了--no-lock，它就只装composer.json里声明的版本，完全跳过锁文件 -
composer update --lock是个误导性参数：它并不存在，Composer 没有这个选项；有人误以为加了就能“只更新 lock”，实际是无效参数，会被忽略
为什么 composer install 有时像“没生成” lock 文件
常见错觉来源是执行环境或权限问题，而非 Composer 主动省略：
- 你在子目录运行
composer install，但composer.json在上层目录 —— Composer 找不到配置，也不会生成 lock - 当前用户对目录无写权限，
composer.lock创建失败，但 Composer 默认不报错（只会静默跳过写入） - CI 环境中设置了
COMPOSER_HOME或COMPOSER_CACHE_DIR指向只读路径，导致写 lock 失败 - 你用的是封装脚本（比如
bin/composer），它内部加了--no-lock或拦截了 lock 写入逻辑
composer update --dry-run 不修改 lock，但你能预判它会怎么改
--dry-run 是唯一能“看变化却不落地”的安全方式。它会完整走一遍依赖解析流程，输出将要安装/升级/降级的包列表，同时告诉你 composer.lock 哪些字段会被更新（比如 version、dist shasum、source type）。
- 它不会真正写文件，但会校验所有约束（
conflict、require-dev、minimum-stability）是否满足 - 如果输出里出现
Would install或Would update，说明真实执行composer update一定会改composer.lock - 注意：它不模拟
--no-dev的效果 —— dev 包仍参与解析，只是不写进 lock 的最终结构里
真正危险的是手动删 lock 后直接 composer install
这不是“不产生 lock”，而是你主动破坏了确定性。此时 Composer 会根据 composer.json 重新计算整个依赖树，结果取决于当前 Packagist 状态、minimum-stability 设置、甚至网络波动（影响 vcs 包的 commit hash 解析）。
- 同一份
composer.json，在不同时间、不同机器上跑出不同的composer.lock，是协作灾难的起点 -
composer why-not在这种场景下也失效 —— 它依赖 lock 里的精确约束链，而你已经把它清空了 - CI 流水线必须用
composer install --no-interaction，而不是update，否则每次构建都可能引入意料外的版本漂移
最常被忽略的一点：Composer 不会因为项目“太小”或“没 require 任何包”就不生成 lock。哪怕 composer.json 只写了 {}，composer install 仍会输出空的 composer.lock（含 packages 为空数组）。所谓“不产生”，几乎总是人为干预或环境异常的结果，不是设计特性。
