Webhook触发的是服务器端脚本执行，而非Composer自动运行；其本质是代码推送事件→服务器接收请求→校验签名后执行git pull和composer install等命令。
Webhook 触发的是服务器行为，不是 Composer 自动执行
Composer 本身不监听 Webhook，所谓“自动部署”，本质是 Gitee/GitHub 推送事件 → 你的服务器接收请求 → 脚本校验后执行 git pull 和 composer install。别在 composer.json 里找 “webhook 配置项”，它根本不存在。
常见错误现象：curl -X POST https://yourdomain.com/webhook.php 手动触发成功，但 Gitee 推送后没反应 —— 大概率是签名验证失败或没勾选「代码推送」。
- Gitee Webhook 必须填
X-Gitee-Token+ Secret，并在 PHP 脚本里用hash_hmac('sha256', $payload, $secret)校验 - GitHub 已弃用手动 Webhook，必须安装 Packagist 官方 GitHub App；否则
https://packagist.org/api/github返回 404 - 脚本运行用户（如
www-data）需对项目目录有读写权限，且能调用composer命令（路径建议写全：/usr/local/bin/composer）
post-install-cmd 不会在生产环境自动跑
你在本地 composer install 时触发的 post-install-cmd，不会因为代码推送到服务器就自动执行。它只在你当前执行命令的机器上跑一次，且默认是开发机。
使用场景：适合本地开发辅助（如生成 IDE 配置），不适合线上部署逻辑。
- 误写
"post-install-cmd": "php artisan migrate"→ 每次本地装依赖都会连开发库跑迁移，极危险 - 想让线上执行？必须显式 SSH 远程调用：
ssh user@prod 'cd /var/www/app && composer install --no-dev' - 更稳妥做法：定义自定义 script 键，如
"deploy:install"，再通过 CI 或运维工具调用composer run deploy:install
vendor 目录不该随 rsync 一起传
直接 rsync -avz ./ user@prod:/var/www/app 同步整个项目（含 vendor/）是高危操作。传输慢、权限错乱、类加载失败，还可能因 COMPOSER_VENDOR_DIR 环境变量导致路径不匹配。
正确路径是在目标机原地执行 composer install，而非搬运已编译的 vendor。
-
rsync命令必须加--exclude="vendor/" --exclude=".git" --exclude="node_modules/" - 远程执行时务必带上
--no-dev --optimize-autoloader --classmap-authoritative，三者缺一不可 - 若目标机没装 Composer，改用临时 phar：
curl -sS https://getcomposer.org/installer | php -- --filename=composer.phar
Packagist 自动同步只认 tag，不认 push
打完 git tag v1.2.0 却没更新？不是缓存问题，而是 Packagist 根本没收到事件 —— 它只响应 create 类型的 tag 事件，不响应普通 push。
关键检查点：
- GitHub App 必须已安装并覆盖该仓库（Settings → Installed GitHub Apps）
-
composer.json的name字段必须和 GitHub 路径完全一致，比如"acme/utils"对应github.com/acme/utils - Tag 名必须是合法语义化版本：
v1.2.0✅，1.2.0✅，release-1.2❌ - 私有仓库必须绑定 GitHub 账户，否则 Packagist 静默跳过，不报错也不提示
真正容易被忽略的是：删 tag、force push tag、修改 tag 注解，都不会触发重同步 —— 只有全新创建的 tag 才算数。
