Webhooks 触发的是服务器行为，非 Composer 自身功能；Gitee Webhook 需配置签名验证（X-Gitee-Token + Secret）、勾选“代码推送”，由服务端脚本校验后执行 composer install/update。
Webhooks 触发的是服务器行为，不是 Composer 自身功能
Composer 本身不监听或响应 Webhooks；所谓“Webhooks 触发
composer
更新”，本质是 Gitee 的 Webhook 推送事件到你自己的服务器，由你写的接收端（比如一个 PHP 脚本或轻量 HTTP 服务）执行
或
。关键不在 Composer 配置，而在服务端如何安全、可靠地响应推送。
Gitee Webhook 配置要点（含签名验证）
Gitee 发送的 POST 请求带
请求头和 JSON body，必须校验签名才能避免被伪造请求触发部署。不能直接裸奔执行
。
在 Gitee 仓库 → 管理 → Webhooks 中添加 URL，如
设置 Secret（自定义字符串），Gitee 会用它对 payload 做 HMAC-SHA256 签名
务必勾选「推送事件」中的「代码推送」（Push Hook）
URL 必须能被公网访问（或内网穿透调试时用 ngrok）
PHP 接收脚本示例（含签名验证 + composer 执行）
以下脚本放在 Web 可访问路径下（如 Nginx 的
），需确保运行用户（如
）有项目目录写权限和
命令可用。
PHP 8.5.5
PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载
常见失败点和绕过陷阱
这个流程看着简单，但 80% 的问题出在环境权限和上下文不一致上：
在 PHP-FPM 下默认禁用，需检查
是否包含
、
等
Web 进程用户（如
）通常没权限执行
（SSH key 权限、known_hosts 问题）——建议改用 HTTPS + Personal Access Token
命令路径可能不是
，用
确认；且需保证该用户能访问
Gitee Webhook 默认超时 10 秒，如果
耗时长（尤其首次），会中断并标记为失败 —— 改用异步队列或后台 nohup 是更稳做法
别把
放在 Web 根目录下可公开访问路径，否则泄露依赖结构
真正要跑通，重点不是写几行 PHP，而是让
git
、composer、权限、网络这四者在同一个用户上下文里安静协作。其他都是锦上添花。
composer installcomposer updateX-Gitee-Tokencomposer installhttps://yourdomain.com/webhook.php/var/www/html/webhook.phpwww-datacomposer#!/usr/bin/env php
&1', $output, $return_code);
if ($return_code !== 0) {
error_log("Git pull failed: " . implode("\n", $output));
exit("Git pull failed\n");
}
// 执行 composer 安装（--no-dev 可选，按需加）
exec('COMPOSER_HOME=/root/.composer /usr/local/bin/composer install --no-interaction --no-dev 2>&1', $output, $return_code);
if ($return_code !== 0) {
error_log("Composer install failed: " . implode("\n", $output));
exit("Composer install failed\n");
}
echo "Done.\n";
exec()disable_functionsexecshell_execwww-datagit pullcomposer/usr/local/bin/composerwhich composerCOMPOSER_HOMEcomposer installcomposer.json