使用 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 构建时，安装了不同版本的依赖
• 引入未经过测试的新版本，造成构建失败或运行时错误
• 破坏“一次构建，到处部署”的原则

这种不确定性在自动化流程中是不可接受的。

jm-jsjkxyjs02-zlm-405

使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。

下载

什么时候才该运行 composer update？

这个操作应仅在开发阶段由开发者手动执行，例如：

• 需要升级某个包到新版本
• 修复安全漏洞并锁定新版本
• 明确测试过新版兼容性后

一旦更新完成并通过测试，新的 composer.lock 应该被提交到版本控制中。

基本上就这些。CI/CD 流程只负责还原已知良好的状态，不是做决策的地方。所以始终用 composer install。不复杂但容易忽略。