request.body为空常见于用request.POST或request.GET读取Webhook数据，因Django默认不解析application/json等原始body，需直接读request.body并注意编码、禁用重复读取、确保验签使用原始字节。
Webhook回调接收时为什么request.body为空
常见于用request.POST或request.GET读取数据，但多数Webhook（如微信、Stripe、GitHub）发的是application/json或application/x-www-form-urlencoded原始body，Django默认不解析这类请求体到POST中。
正确做法是直接读request.body，并注意编码问题：
-
request.body是bytes类型，需用.decode('utf-8')转为字符串（除非明确是二进制） - 若前端发的是JSON，用
json.loads(request.body)；若为表单格式，可用QueryDict手动解析：from django.http import QueryDict; data = QueryDict(request.body, encoding='utf-8') - 别在视图里调用
request.POST后再读request.body——Django会清空原始流，导致二次读取返回空
验签失败的三个高频原因
验签逻辑本身简单，但实际部署中90%的问题出在数据预处理不一致。以微信支付回调为例，签名基于原始报文拼接+HMAC-SHA256，而Django默认可能已做URL解码、字段重排序、空格/换行归一化等。
- 确保验签前使用的原始字节与微信发送的完全一致：禁用
request.POST，用request.body原始值；若用QueryDict解析，必须保持字段顺序，并确认urlencode时未对特殊字符重复编码 - 密钥（
key或app_secret）是否被意外截断或含不可见字符？建议从环境变量读取后用strip()清理 - 时间戳、随机串等字段是否被Django中间件自动转换类型？例如
int转str后丢失前导零，或float精度损失——验签必须用原始字符串值
如何安全地写一个无CSRF的Webhook视图
Django默认对所有POST请求校验CSRF token，但Webhook由第三方服务发起，无法携带token。硬关全局CSRF或加@csrf_exempt有风险，应精准控制。
立即学习“Python免费学习笔记（深入）”；
- 用
@csrf_exempt装饰函数视图即可，无需额外配置；类视图需在dispatch方法上装饰，或继承CsrfExemptMixin（需自定义） - 务必配合IP白名单或签名验证——
@csrf_exempt只是移除token检查，不代表跳过业务校验 - 避免将该视图暴露在通用URL下（如
/webhook/），改用带随机路径的专用端点，例如/webhook/v1/stripe_8a3f9b/，降低被探测概率
异步处理Webhook时要注意什么
Webhook要求快速响应（通常5秒内返回HTTP 200），否则发送方可能重试。但验签、数据库写入、发消息等操作可能超时，不能全在同步视图里完成。
- 验签和基础参数校验必须同步完成——这是安全边界，不能放到任务队列里
- 通过
django-rq或celery投递后续任务时，把request.body和必要头信息（如X-Hub-Signature-256）作为参数传入，避免在异步任务里再读请求上下文（已销毁） - 记录原始请求日志时，注意敏感字段脱敏（如
card_number、id_token），且日志级别设为INFO或更低，避免误打调试信息到生产日志
最易被忽略的是：验签用的密钥更新后，旧签名仍可能在重试窗口内到达，服务需支持多版本密钥并存，而不是直接替换——这在微信、支付宝等平台升级密钥时很常见。
