能实现，但必须分清「谁触发」「谁执行」「谁校验」——GitHub/Gitee 的 WebHook 只负责发通知，宝塔本身不内置 Git 服务，需靠 Shell 脚本 + git 命令 + 权限控制三者配合，漏一环就拉不下来代码。
能实现，但必须分清「谁触发」「谁执行」「谁校验」——GitHub/Gitee 的 WebHook 只负责发通知，宝塔本身不内置 Git 服务，得靠 Shell 脚本 + git 命令 + 权限控制三者配合，漏一环就拉不下来代码。
WebHook 触发后，宝塔怎么知道该更新哪个网站？
宝塔的 WebHook 功能本身不解析 GitHub/Gitee 的 payload 内容，它只把原始 JSON 当作环境变量传给脚本。所以关键在脚本里用 $1 接收你手动传入的参数（比如网站目录名），而不是指望 WebHook 自动识别仓库名。
- GitHub 设置 WebHook 时，
Payload URL要写成类似https://your-server.com:8888/hook?param=site_a的形式，其中param=site_a就是传给脚本的$1 - Gitee 同理，但它的 WebHook 不支持 URL 参数，得改用「自定义 HTTP 头」或直接在宝塔 WebHook 页面里固定填入目录名（如
site_b）作为脚本参数 - 脚本开头必须加判断：
if [ ! -n "$1" ]; then echo "param参数错误"; exit 1; fi，否则空参数会导致cd /www/wwwroot/这种危险操作
git pull 失败的常见原因和修复方式
90% 的失败不是 WebHook 没触发，而是脚本执行时权限或上下文不对。宝塔 WebHook 默认以 www 用户身份运行，但 www 用户通常没权限执行 git、没 SSH key、甚至没 HOME 目录。
- 确保
git已安装且可被www用户调用：sudo -u www git --version，如果报 command not found，需用sudo ln -s /usr/bin/git /www/server/panel/pyenv/bin/git建软链（路径依系统而定） - SSH key 必须属于
www用户：sudo -u www ssh-keygen -t rsa -f /www/.ssh/id_rsa -N ""，然后把公钥加到 GitHub/Gitee，再测试：sudo -u www ssh -T git@github.com - 不要在脚本里用
sudo git pull——sudo会切换用户，导致 SSH key 找不到；应始终用sudo -u www git pull显式指定用户 - 首次部署时，目录可能为空，得先
git clone；后续才git pull，脚本里必须用[ -d ".git" ]判断，不能只靠git pull报错来兜底
多个网站共用一个 WebHook 地址，怎么避免互相覆盖？
不能让所有网站都监听同一个 URL，否则一次 push 会触发全部站点执行 git pull，极大概率出错。正确做法是每个网站配独立 WebHook 地址 + 独立脚本入口，或用单个脚本靠参数分流。
- 推荐用「参数分流」：在宝塔 WebHook 设置页，为每个网站创建独立任务，每个任务调用同一脚本但传不同
$1，例如：/www/scripts/deploy.sh site_a、/www/scripts/deploy.sh site_b - 脚本内用
case "$1" in site_a) gitPath="/www/wwwroot/site_a";; site_b) gitPath="/www/wwwroot/site_b";; *) echo "未知站点"; exit 1;; esac分支处理 - 绝对禁止在脚本里写死路径（如
cd /www/wwwroot/myapp），否则改一个网站就得改一次脚本，失去复用性 - 同步前加锁机制可选但非必需：
if [ -f "/tmp/deploy.lock" ]; then echo "deploy running"; exit 1; fi; touch /tmp/deploy.lock; trap 'rm -f /tmp/deploy.lock' EXIT，防止并发 push 导致冲突
最易被忽略的一点：WebHook 请求超时默认只有 10 秒，而大仓库 git pull 可能卡在 delta 解包阶段。如果发现「GitHub 显示 delivered，但服务器没反应」，先检查宝塔 WebHook 日志里有没有超时记录，再把脚本开头加上 timeout 60s 包裹关键命令，并确保服务器时间与 GitHub 时间偏差小于 5 分钟（否则签名验证失败）。
