命令 composer update --no-dev --lock 用于在CI中验证生产依赖的lock文件一致性，仅重新计算composer.lock中的content-hash而不安装包；02. 它结合--no-dev忽略开发依赖、--lock不写入磁盘的特性，在git diff校验下确保提交的lock文件与当前配置同步，防止部署偏差。
当你在CI（持续集成）环境中运行 composer update --no-dev --lock 时，这个命令组合的作用是：仅更新 composer.lock 文件中生产依赖（非开发依赖）的哈希值（如内容校验和、版本锁定等），而不实际安装或更新任何包。
理解每个选项的作用
--no-dev：告诉 Composer 忽略 require-dev 中定义的开发依赖。这意味着只关注 require 中列出的生产依赖。
--lock：这个选项的意思是“只更新 lock 文件”，不执行实际的包下载或文件写入操作。Composer 会解析依赖关系，重新计算 lock 文件中的元数据（比如 content-hash），但不会改变 vendor 目录。
为什么在 CI 中使用它？
在 CI 流程中，你可能希望验证composer.lock 文件是否与当前 composer.json 一致。如果开发者忘记提交更新后的 lock 文件，会导致部署不一致。运行 composer update --no-dev --lock 可触发以下行为：- 重新生成 lock 文件中的
content-hash，该哈希基于当前composer.json和 PHP 环境约束计算得出 - 检查现有的
composer.lock是否已经反映了最新的依赖状态 - 如果 lock 文件过期（hash 不匹配），命令会失败或输出变更（取决于环境）
这常用于 CI 中的“验证步骤”——确保开发者已经正确运行了 composer install 或 composer update 并提交了最新的 lock 文件。
典型 CI 使用场景
例如，在 GitHub Actions 或 GitLab CI 中：script: - composer update --no-dev --lock - git diff --exit-code composer.lock这段脚本的意思是：
- 尝试更新 lock 文件（仅限生产依赖）
- 如果有变更（说明本地 lock 文件未同步），
git diff --exit-code会返回非零退出码，导致 CI 失败
composer update 并提交 composer.lock。基本上就这些 —— 这个命令组合不是为了安装代码，而是为了保证 lock 文件的完整性与一致性，特别是在自动化流程中防止遗漏关键变更。
