composer install 本不更新 lock 文件，若被修改说明环境或命令越界；常见原因包括 lock 缺失、格式损坏、json 被手动修改未同步，或 CI/Docker 中漏拷贝 lock；唯一确保 lock 不变的命令是 composer install --locked。
composer install 本来就不更新 lock 文件——你看到它被改了，说明环境或命令本身已经越界了。
为什么 composer install 后 composer.lock 还是变了？
不是 Composer “想更新”，而是它发现当前状态无法安全复现锁文件，只能“修复”：要么重建，要么重写。常见触发点包括：
-
composer.lock文件为空、JSON 格式损坏，或缺失packages字段（Composer 会静默生成新 lock） - 执行前删过
composer.lock，但没意识到composer install在无 lock 时根本不会报错——某些旧版 Composer 会 fallback 生成，新版则直接报错No composer.lock file present -
composer.json被手动改过（比如加了新包、改了 PHP 版本约束），但没跑composer update同步 lock，导致 install 时检测到不一致，自动“对齐”并重写 lock - CI/CD 中
COPY了composer.json却漏掉composer.lock，Docker 构建时实际执行的是composer update行为（因为无 lock 可读）
真正能锁死 lock 文件不改动的命令：用 --locked
--locked 是唯一硬性保障：它不妥协、不 fallback、不生成，只校验——lock 必须存在，且内容必须与 composer.json 兼容，否则立即失败。
- ✅ 正确用法：
composer install --locked --no-dev --no-interaction --no-scripts - ❌ 不兼容参数：
--dry-run、--with、--ignore-platform-reqs等都会被拒绝 - ⚠️ 兼容性判断示例：lock 里记的是
"monolog/monolog": "2.10.0"，json 写的是"^2.0"→ 允许；但如果 lock 记的是"3.0.0"，json 还是"^2.0"→ 直接报错退出 - ? 生产部署脚本里，这行命令应是标准配置，而不是可选项
CI/CD 和 Docker 中最容易踩的坑
不是命令写错了，而是上下文污染了“一致性”这个前提：
- Dockerfile 里先
COPY composer.json .，再RUN composer install，却没COPY composer.lock→ 实际行为等价于composer update，构建不可重现 - Git 分支切换后残留旧版
composer.json或未清理 vendor，导致 Composer 检测到 schema 差异，强制重建 lock - 多个项目共享
COMPOSER_HOME缓存，其中混入了其他项目的 lock 模板（尤其多阶段构建中曾出现） - CI 流水线没加校验：
git status --porcelain composer.lock非零就中断构建 —— 这是最便宜也最有效的兜底手段
别信“忽略 lock”的伪需求
不存在 --ignore-lock、--no-lock 或 --skip-lock 这类参数。Composer 不提供绕过 lock 的开关，因为它的设计哲学就是「锁即契约」。
- 想跳过 lock？只有两个真实路径：
composer update（主动刷新），或rm composer.lock && composer install（彻底重算）——但后者等于撕毁契约，团队协作中应视为高危操作 -
composer install --no-lock是个反直觉的陷阱：它不是“忽略 lock”，而是“完全不读 lock”，此时 Composer 退化成按composer.json解析安装，行为等同于update，且不生成 lock - 如果你真需要动态解析依赖（比如 SDK 模板项目），应该用
composer create-project或明确文档说明“本项目不提交 lock”
真正难的不是记住哪个参数，而是让整个流程始终处于「lock 存在 + json 未被悄悄改 + 命令不越权」这个三角闭环里。一旦漏掉一角，Composer 就会按自己的逻辑补全——而它补的，往往不是你想要的。
