GitHub Webhook比轮询更可靠，因其避免漏事件、节省资源且符合API规范；Webhook由仓库主动推送，只要服务返回200 OK即可实时接收Issue事件。
GitHub Webhook 为什么比轮询更可靠
直接用 GitHub 的 Webhook（事件回调）而不是定时轮询 /issues API，核心原因是避免漏事件、省资源、合规——GitHub 明确要求高频轮询必须加缓存和节流，且 rate limit（X-RateLimit-Remaining）耗尽后会返回 403 Forbidden。Webhook 是仓库侧主动推送，只要你的服务能响应 200 OK，Issue 创建瞬间就能收到。
但注意：Webhook 默认只发到公网可访问的 URL；本地开发时得用 ngrok 或 localtunnel 暴露端口，否则 GitHub 后台配置会提示 “Unable to deliver payload”。
如何用 Flask 快速接收并解析 Issue webhook
Flask 是最轻量的选择，几行代码就能启动一个能被 GitHub 认证的 endpoint。关键不是“怎么写路由”，而是“怎么验签”——GitHub 会在 X-Hub-Signature-256 头里放 HMAC-SHA256 签名，你必须用自己设置的 webhook secret 重新计算比对，否则任何伪造请求都能触发逻辑。
- 用
request.headers.get("X-Hub-Signature-256")取签名（格式是sha256=xxx） - 用
hmac.new(secret.encode(), request.get_data(), digestmod=hashlib.sha256).hexdigest()算出期望值 - 用
hmac.compare_digest()安全比对（防时序攻击） -
request.json里action == "opened"才是新 Issue，别漏判edited或reopened
from flask import Flask, request
import hmac, hashlib
app = Flask(__name__)
SECRET = "your_webhook_secret_here"
@app.route("/webhook", methods=["POST"])
def handle_webhook():
sig = request.headers.get("X-Hub-Signature-256")
if not sig or not sig.startswith("sha256="):
return "Bad signature", 400
expected = hmac.new(SECRET.encode(), request.get_data(), hashlib.sha256).hexdigest()
if not hmac.compare_digest(sig[7:], expected):
return "Invalid signature", 401
payload = request.json
if payload.get("action") == "opened" and payload.get("issue"):
print("New issue:", payload["issue"]["html_url"])
return "", 200
Webhook 配置里最容易填错的三个字段
进仓库 Settings → Webhooks → Add webhook，这三个地方错一个，就收不到事件：
在 OpenClaw 中管理 GitHub 仓库、Pull Request、Issue 与工作流。适用于审查 PR、管理 Issue、自动化 GitHub Actions、同步仓库等场景。
立即学习“Python免费学习笔记（深入）”；
-
Payload URL：必须是完整 HTTPS 地址（哪怕用 ngrok），不能带路径参数，例如https://abc123.ngrok.io/webhook，结尾不加?或# -
Which events would you like to trigger this webhook?：勾选Issues，别只勾Pushes或误选Let me select individual events却漏掉Issues -
Secret：必须和代码里SECRET完全一致，区分大小写，不能有多余空格；复制粘贴时尤其容易带 invisible Unicode 字符
填完点 Add webhook 后，立刻点右边的 Recent Deliveries 查看第一条测试事件的响应状态码和响应体——如果显示 Connection timed out，说明你的服务没起来或域名不可达；如果显示 401 Unauthorized，基本就是 secret 不匹配。
收到 Issue 后该做什么才不算白接
单纯 print 出来只是验证通路，真要监控，得做三件事：去重、归档、通知。GitHub 可能因网络问题重发同一事件（X-GitHub-Delivery 头唯一），所以别光靠 issue.number 去重——同一个 Issue 可能多次 opened（比如先 close 再 reopen）。
- 用
(repository.full_name, issue.number, action)三元组当唯一 key 存 Redis 或 SQLite，避免重复处理 - 提取
issue.title、issue.user.login、issue.created_at和issue.labels，按需入库或写日志 - 发通知别硬编码邮件或钉钉——用环境变量控制通道，比如
NOTIFY_CHANNEL=dingtalk，再调对应 SDK，否则上线后改代码太麻烦
Webhook 是“尽力投递”，不保证 100% 到达，也不保证顺序。如果业务强依赖不丢事件，得配合定期补漏：每天跑一次 GET /repos/{owner}/{repo}/issues?state=all&sort=created&direction=desc&per_page=100，对比本地最新 created_at 时间戳。
