composer.lock 被修改的根本原因是：无有效 lock 文件时 install 会自动生成，或执行了 update 等变更依赖图谱的命令；确保不改动需用 --locked 参数并校验 lock 存在且兼容。
composer install 时为什么 lock 文件会被修改？
根本原因在于：你执行了 composer install，但当前目录没有 composer.lock 文件，或者它内容为空/损坏。Composer 会自动生成一个新 lock 文件，而不是报错或跳过——这容易被误认为“被更新了”。另外，如果运行的是 composer update（哪怕只改了一个包），lock 文件必然重写。
如何确保 lock 文件完全不改动？
核心原则：只运行真正“安装依赖”的命令，且环境必须满足前提条件。以下是关键操作点：
- 确认已存在有效的
composer.lock文件（非空、JSON 格式合法、包含packages字段） - 始终使用
composer install --no-interaction --no-scripts（加--no-scripts可避免某些插件触发意外写入） - 禁止在 CI/CD 或部署脚本中出现
composer update、composer require、composer remove等任何会变更依赖图谱的命令 - CI 中可加校验步骤：
git status --porcelain composer.lock，非零退出即说明 lock 被动了，立刻中断构建
CI 部署中 lock 文件意外变更的常见诱因
不是 Composer 本身有问题，而是上下文干扰。典型场景包括：
- 项目根目录下存在
composer.json的多个版本（比如分支切换后未 clean，导致composer install检测到 schema 变更而重建 lock） - 使用了
COMPOSER_HOME共享缓存，而该缓存目录里有残留的旧版composer.lock模板（极少见，但曾出现在某些 Docker 多阶段构建中） -
composer.json中用了^或~版本约束，且 lock 文件里对应包的 version 字段缺失或格式异常（Composer 会尝试“修复”并重写 lock） - 执行命令前没清空 vendor 目录，而 Composer 在检测不一致时选择“以 lock 为准重装”，但过程中因权限或 symlink 问题 fallback 到生成新 lock
想锁死所有行为？用 --locked 参数
这是最硬核也最安全的方式：composer install --locked。它强制要求：lock 文件必须存在且与 composer.json 兼容，否则直接失败，绝不动手生成新 lock。
注意两点：
-
--locked不兼容--dry-run，也不接受任何版本覆盖参数（如--with） - 如果你的 lock 文件里记录的是
"monolog/monolog": "2.10.0"，但composer.json写的是"monolog/monolog": "^2.0"，它仍能通过；但如果 lock 里是"monolog/monolog": "3.0.0"而 json 里是"^2.0"，就会报错退出
生产环境部署脚本里，composer install --locked --no-dev --no-interaction 应该是标准配置。少一次侥幸，就少一个凌晨三点的线上故障。
