使用 composer install 能确保CI/CD构建可重复稳定，因为它依据 composer.lock 安装确切依赖版本，保证环境一致、避免意外问题且执行速度快；而 composer update 会拉取符合约束的最新版本，可能导致不同时间构建安装不同依赖，引入未测试变更，破坏“一次构建，到处部署”原则；因此 composer update 应仅在开发阶段手动执行，更新后提交新的 composer.lock，CI/CD 流程始终用 composer install 还原已知良好状态。
在CI/CD流程中，应该使用 composer install，而不是 composer update。
为什么用 composer install？
CI/CD 的目标是确保构建可重复、稳定且与本地环境一致。使用 composer install 能实现这一点，因为它：
- 根据项目根目录下的 composer.lock 文件安装确切版本的依赖
- 保证每次部署时使用的依赖版本完全相同，避免因依赖变动导致的意外问题
- 执行速度快，不需要解析最新版本或检查更新
只要你的团队在开发过程中正确提交了 composer.lock 文件，CI/CD 环境就能还原出一致的依赖状态。
为什么不能用 composer update？
composer update 会根据 composer.json 中的版本约束去拉取最新的匹配版本，这可能导致：
- 不同时间运行 CI 构建时，安装了不同版本的依赖
- 引入未经过测试的新版本，造成构建失败或运行时错误
- 破坏“一次构建，到处部署”的原则
这种不确定性在自动化流程中是不可接受的。
什么时候才该运行 composer update？
这个操作应仅在开发阶段由开发者手动执行，例如：
- 需要升级某个包到新版本
- 修复安全漏洞并锁定新版本
- 明确测试过新版兼容性后
一旦更新完成并通过测试，新的 composer.lock 应该被提交到版本控制中。
基本上就这些。CI/CD 流程只负责还原已知良好的状态，不是做决策的地方。所以始终用 composer install。不复杂但容易忽略。
