用 fetch 发送 POST 请求测 Webhook 更可靠，需手动设 Content-Type: application/json、JSON.stringify body、加 try/catch；用 编辑 payload 并校验语法；按钮禁用防重复提交；本地测试用 ngrok 暴露 HTTPS 地址；务必对照文档确认格式、签名等要求。
用 fetch 发送 POST 请求就能测 Webhook，别搞表单提交
表单提交（<form method="POST"></form>）默认是 application/x-www-form-urlencoded，而绝大多数 Webhook 服务只认 application/json。直接用 fetch 控制请求头和 body，才是干净、可控的做法。
- 必须手动设置
Content-Type: application/json，否则接收方可能解析失败 -
body要用JSON.stringify()包一层，不能直接传对象 - 加个
try/catch捕获网络错误或 4xx/5xx 响应，不然静默失败很难排查 - 示例 payload 尽量贴近真实场景：比如含
event、data、timestamp字段，避免只写{"test":true}
HTML 中的 <textarea></textarea> 是最稳妥的 payload 编辑方式
用户要改 JSON，用 <input type="text"> 容易误删引号、逗号，还无法换行；用 <textarea></textarea> 可粘贴、可缩进、可校验格式，体验和调试成本都低得多。
- 给
<textarea></textarea>加spellcheck="false"关掉拼写检查，避免下划红线干扰 - 初始值建议用合法 JSON 示例，比如：
{"event":"user.created","data":{"id":"usr_123","email":"test@example.com"},"timestamp":1717029840} - 点击发送前，先
JSON.parse()校验内容是否合法——捕获SyntaxError并提示“JSON 格式错误”，比发出去再被服务器拒收更早发现问题
按钮禁用 + 状态反馈能避免重复提交和误判
Webhook 接口通常不幂等，点两下可能触发两次事件；没反馈时用户会狂点，结果后端收到一堆重复请求。
- 点击后立刻
button.disabled = true，并把文案改成“发送中…” - 无论成功失败，3 秒后自动恢复按钮，并清空状态（不要留“成功！”一直挂着，容易误导下次操作）
- 响应体建议只显示前 200 字符（用
response.text().then(t => t.slice(0,200))），防止大日志撑爆页面 - HTTP 状态码要显式展示，比如
400 Bad Request或502 Bad Gateway，这是定位问题的第一线索
本地测试时，localhost 域名可能被某些 Webhook 服务拒绝
不少平台（如 Stripe、GitHub）明确要求 Webhook URL 必须是公网 HTTPS 地址，http://localhost:8080 直接被拦在门外，不是代码问题，是策略限制。
立即学习“前端免费学习笔记（深入）”；
- 开发阶段优先用
ngrok或cloudflared tunnel暴露本地端口，拿到真实 HTTPS URL 再配到平台后台 - 如果只是验证 payload 结构，可用在线工具如
webhook.site或requestbin.com，它们提供临时 endpoint 和完整请求记录 - 切记：别在 HTML 里硬编码生产环境 URL，用
<input type="url">让用户自己填，避免误发测试请求到线上
