用浏览器开发者工具抓Webhook真实请求需在Network面板勾选Preserve log，关注Other/XHR中后台触发的非页面加载请求；若遇302跳转，检查Headers中Location；通过搜索X-Hub-Signature-256等特有请求头快速定位。
怎么用浏览器开发者工具抓到 Webhook 的真实请求
Webhook 不是前端主动发起的，所以 fetch 或 XMLHttpRequest 面板里默认看不到。真正要盯的是 Network 面板里的 Other 或 XHR 分类下那些「非页面加载触发」的请求——尤其是你刚在后台点完「测试发送」后突然冒出来的那条。
- 必须勾选
Preserve log，否则页面刷新或跳转后记录就清空了 - 如果目标服务用了 302 跳转或重定向，记得点开请求详情看
Headers里的Location，真正的 Webhook 请求可能藏在跳转后的 URL 里 - 某些平台（比如 GitHub、Stripe）发 Webhook 时会带
X-Hub-Signature-256这类头，直接在Request Headers区域搜这个字段能快速定位
本地起一个临时 HTTP 服务接收 Webhook 并打印日志
别用 curl 手动模拟——它没法体现真实 Webhook 的 header、body 编码、重试机制。最稳的方式是起个最小化服务，把每次请求原样存成 JSON 文件或打到控制台。
- Node.js 用户可以直接跑：
node -e "require('http').createServer((req, res) => {let d='';req.on('data', c => d+=c);req.on('end', () => {console.log({method:req.method,headers:req.headers,body:d});res.end('ok')}).listen(3000)" - Python 用户推荐用
http.server配合-m：运行python3 -m http.server 3000 --bind 127.0.0.1:3000不行，它不解析 POST body；得写三行脚本读sys.stdin.buffer.read() - 注意端口：很多 Webhook 平台（如 Slack、Shopify）只允许 HTTPS 回调，本地测试得配 ngrok 或使用
localhost白名单（GitHub 支持，但 Stripe 不支持）
为什么收到的 body 是空的或乱码
不是代码写错了，大概率是 Content-Type 和解析方式没对上。Webhook 常见三种 payload 格式：application/json、application/x-www-form-urlencoded、text/plain，服务端必须按对应方式读流。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
application/json：必须用JSON.parse()解析，且确保req.setEncoding('utf8')已设，否则中文变\u4f60类似转义 -
application/x-www-form-urlencoded：不能直接JSON.parse()，得用querystring.parse()（Node）或parse_qs()（Python） - 某些平台（如 Discord）发的是
multipart/form-data，但极少用于 Webhook；若真遇到，说明配置出错，应检查平台文档是否误启了文件上传开关
怎么构造一个带签名验证的测试请求（比如 GitHub Webhook）
平台要求验证 X-Hub-Signature-256，不是为了让你“学会加密”，而是防止日志伪造。你只需要复现它的计算逻辑，把本地请求伪装成合法 Webhook。
立即学习“前端免费学习笔记（深入）”；
- GitHub 的签名是
sha256=+hmac(secret, body, 'sha256').digest('hex')，secret 必须和你在仓库设置里填的一模一样（含空格） - 用
curl发送时，body 必须是原始字节流，不能经过 JSON.stringify 后再被 shell 转义；推荐先写入文件，再用--data-binary @payload.json - 常见翻车点：
echo '{"a":1}' | curl -H "X-Hub-Signature-256: ..." -d @- http://localhost:3000中的@-会让 curl 读 stdin，但 echo 默认带换行，导致签名验不过
Webhook 日志的本质是「请求快照 + 上下文还原」，不是记流水账。最容易被忽略的，是平台在重试失败请求时会改 X-GitHub-Delivery 头但不改 body，同一份日志里看到多个相同 X-Hub-Signature-256 却不同时间戳，大概率是重试行为，不是重复触发。
