Composer团队里有人乱动Lock？加入Git预提交钩子【避坑】-composer-PHP中文网

composer.lock 必须与 vendor/ 严格一致，否则导致 ci 失败、环境不一致；误改主因是 ide 自动 update 或 require 忘加 --no-update；pre-commit 钩子可校验 lock 是否匹配 install --dry-run 结果。

composer团队里有人乱动lock？加入git预提交钩子【避坑】

只要项目用了 composer install 而不是 composer update，composer.lock 就必须和 vendor/ 严格一致——否则 CI 构建失败、本地环境不一致、依赖版本漂移全会找上门。

为什么 `composer.lock` 经常被误改？

常见原因不是故意，而是 IDE 自动执行了 composer update（比如 PhpStorm 的“auto-update dependencies”开关开着），或开发者顺手敲了 composer require 却忘了加 --no-update，又或者在 CI 流水线里混用了 update 和 install。

这类改动往往悄无声息：没有报错，git status 显示只有 composer.lock 变了，人一疏忽就 git add -A && git commit 了。

composer update 会重写整个 composer.lock，哪怕只改了一个包的小版本
composer require foo/bar 默认触发更新，等价于 composer update foo/bar
Git 不校验文件内容逻辑，只认“变了就提交”，它不管这变的是不是破坏性变更

用 `pre-commit` 钩子拦截非法修改

核心思路：在 git commit 前，检查当前暂存区里有没有 composer.lock，如果有，就验证它是否与 composer install --dry-run 产出的“应有状态”一致。

Git Changelog Generator

使用约定式提交（Conventional Commits）从 Git 历史记录中生成结构化变更日志，支持多种格式、AI 增强型描述以及可自定义的范围……

下载

把下面这段脚本存为 .git/hooks/pre-commit（记得 chmod +x）：

#!/bin/sh
if git diff --cached --quiet -- composer.lock; then
  exit 0
fi
<p>if ! composer install --dry-run --no-interaction >/dev/null 2>&1; then
echo "❌ composer.lock 不匹配 vendor/ 或 composer.json —— 请先运行 composer install"
exit 1
fi</p>

--dry-run 不真的写文件，只做校验；失败说明 lock 和 json 或 vendor/ 对不上
钩子只检查暂存区里的 composer.lock，避免干扰日常开发中还没 git add 的临时修改
如果项目没装 Composer，或 vendor/ 不存在，--dry-run 也会失败，正好暴露环境问题

别漏掉 CI 和团队协作的配套动作

预提交钩子只是第一道防线，不能替代流程规范。

CI 脚本里必须用 composer install --no-dev --prefer-dist，且禁止出现 composer update
所有 composer require 操作都该加 --no-update，后续统一跑 composer update 并提交 lock（需明确 PR 描述）
在 README.md 里写清楚：“改依赖 → 先 composer require --no-update → 提交 composer.json → 后续由专人合并并更新 lock”
如果团队用 GitHub/GitLab，建议开启 branch protection，禁止直接 push 到 main，强制走 PR + CI 校验