Composer 本身不参与 Git 提交规范，Husky 是 Node.js 工具，在 PHP 项目中无法运行；PHP 项目应使用 Git 原生钩子（如 pre-commit）调用 php-cs-fixer 等 PHP CLI 工具进行校验。
Composer 不参与 Git 提交规范 —— 这是个常见误解。你看到的「Composer + Husky」组合，大概率是混淆了前端与 PHP 生态的工具链。Husky 是 Node.js 生态的 Git Hook 工具，只在 npm/yarn 项目中生效；而 Composer 是 PHP 的依赖管理器，本身不提供钩子机制，也不能直接拦截 git commit。
如果你的项目是 PHP（比如 Laravel、Symfony），想做提交前校验，得换一套方案。
Husky 在 PHP 项目里根本跑不起来
- Husky 的安装依赖
npm或yarn，会往.git/hooks/写 shell 脚本，并通过node执行； - PHP 项目没
package.json，也没node_modules，husky install会直接失败； - 即使硬塞一个
package.json进去，也违背工程一致性 —— 开发者要同时维护两套依赖和脚本环境，容易出错且难以交接。
常见的错误现象：
- 执行
git commit无任何校验，husky钩子静默失效； -
git hooks目录下没生成pre-commit文件，或生成了但权限不对（Windows 上尤其常见）； - 控制台报错
sh: husky: command not found或Cannot find module 'husky'。
PHP 项目该用什么替代 Husky？
真正可行的方案是用 Git 原生钩子 + PHP CLI 工具：
-
pre-commit钩子用 shell 脚本写，调用phpstan、psalm、phpcs或php-cs-fixer； - 不依赖 Node，所有校验命令都走
php可执行文件； - 配置统一放在项目根目录，例如
.git/hooks/pre-commit（需chmod +x）；
示例钩子内容（简化版）：
Convert Github Repository
下载
适用于以下场景：（1）用户提供 GitHub 仓库 URL 或本地仓库路径，并请求将其转换为其他格式；（2）用户请求导出 GitHub 仓库……
#!/bin/sh echo "Running PHP code style check..." if ! vendor/bin/php-cs-fixer fix --dry-run --using-cache=no; then echo "❌ Code style check failed. Please run 'vendor/bin/php-cs-fixer fix' and commit again." exit 1 fi
注意点：
-
php-cs-fixer必须已通过composer require --dev friendsofphp/php-cs-fixer安装； - 钩子脚本必须有可执行权限：
chmod +x .git/hooks/pre-commit； - 团队成员需手动复制或用脚本初始化钩子，无法像 Husky 那样自动注册（这点最容易被忽略）。
为什么不能用 commitizen + commitlint 管 PHP 提交？
可以，但得绕开 Husky：
-
commitizen是命令行工具，只要本地装了npm就能运行git cz，和语言无关； - 但
commitlint校验必须挂到commit-msg钩子上 —— PHP 项目没 Husky，就得自己写一个.git/hooks/commit-msg脚本，再调用npx commitlint --edit $1； - 这意味着每个开发者都要装 Node，并确保
npx可用，实际落地成本高，易出兼容问题（比如 Windows 下路径空格、PowerShell 编码乱码导致commitlint.config.js读取失败）。
更现实的做法：
- 用纯 PHP 实现提交信息校验（如
php -r "preg_match(...)"）； - 或干脆放弃自动化校验，改用 VS Code 提交模板 + 团队约定（比如在
.gitmessage里预置格式）； - 复杂度和维护成本之间，往往后者更可持续。
真正卡住团队落地的，从来不是工具选型，而是钩子如何分发、如何保持更新、出错了谁来 debug。Node 工具链在 PHP 项目里属于“外来户”，强行嫁接只会让问题更隐蔽。
