GitHub Issue自动回复需PAT含issues和repository_contents权限，轮询API监听新Issue并用since参数优化，回复前校验bot评论或标签防循环，内容嵌入模板指引、排查步骤和响应预期。
GitHub Issue自动回复依赖哪些API权限？
必须用 personal access token（PAT）调用 GitHub REST API，且该 token 至少要带 issues 和 repository_contents 权限。仅用 public_repo 不够——它不包含对 Issue 评论的写权限，会返回 403 Forbidden 错误。
生成 token 时务必勾选：issues、repository_contents（用于读取仓库内容，比如检查是否含 .github/ISSUE_TEMPLATE），如果还要自动关闭 Issue 则加 admin:org 或更细粒度的 write_issues（取决于 GitHub 版本）。
别把 token 硬编码进脚本——用环境变量 GITHUB_TOKEN 传入，否则泄露风险极高。
如何监听新 Issue 并触发回复逻辑？
GitHub 不提供实时推送的「Issue 创建」事件 Webhook 免费订阅（私有库可配，但公开库默认只支持部分事件）。最稳妥的实操方式是轮询：GET /repos/{owner}/{repo}/issues?state=open&sort=created&direction=desc&per_page=10，每次取最新 10 条，比对本地缓存的最新 id 或 created_at 时间戳。
关键点：
- 用
since参数（ISO8601 时间字符串）替代全量拉取，降低请求压力 - 每次请求后记录最大
id到本地文件（如last_issue_id.txt），避免重复处理 - 注意分页：即使只取 10 条，也要检查响应头
Link是否含rel="next"，防止漏掉边界情况 - 不要高频轮询（如每秒一次）——GitHub 有速率限制（未认证 60 次/小时，带 token 5000 次/小时），建议间隔 ≥60 秒
怎样构造合规又实用的自动回复内容？
直接发「感谢提交！」太单薄，用户真正需要的是引导。推荐在回复中嵌入三类信息：模板指引、常见排查步骤、人工响应预期。
示例代码片段（使用 requests.post）：
response = requests.post(
f"https://api.github.com/repos/{owner}/{repo}/issues/{issue_number}/comments",
headers={"Authorization": f"token {token}"},
json={"body": "? 感谢提交 Issue！\n\n✅ 请确认已按 [ISSUE_TEMPLATE](.github/ISSUE_TEMPLATE/bug_report.md) 填写必要字段。\n? 可先尝试：`pip install --upgrade your-package` 或检查 `requirements.txt` 版本。\n⏳ 我们通常在 2 个工作日内人工响应。"}
)
注意：body 必须是纯字符串，不能含未转义的 \n 以外的控制字符；链接用绝对路径（如 .github/ISSUE_TEMPLATE/...）会被 GitHub 自动渲染为相对仓库的链接。
为什么自动回复后 Issue 还被反复触发？
这是最常见的陷阱：你的 bot 账号发的评论，也会触发后续的 Issue 事件（比如 Webhook 接收或下一轮轮询），导致无限循环回复。
解决办法只有两个：
- 在回复前检查该 Issue 是否已有 bot 的评论——用
GET /repos/{owner}/{repo}/issues/{issue_number}/comments拉取全部评论，过滤user.login == bot_username - 或者更轻量：在首次回复后，给 Issue 打上标签（如
bot-replied），后续轮询时跳过带该标签的 Issue（需额外请求GET /repos/{owner}/{repo}/issues/{issue_number}查labels字段）
别依赖「只处理 state=‘open’」——用户可能 reopen 已关闭的 Issue，这时仍需判断是否已回复过。
实际部署时，时间戳缓存、ID 记录、标签校验这三层防护最好都加上，尤其当仓库 Issue 量大或 bot 需多实例运行时。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
