webhooks 接收 xml 的核心是禁用默认 json 解析器，改用 raw 中间件获取原始字节流，再校验 content-type、编码、根节点和签名，最后异步处理以避免超时。
WebHooks 接收 XML 的核心是「别用默认 JSON 解析器」
绝大多数 WebHook 框架（如 Express、FastAPI、Flask 默认配置）会自动尝试将请求体解析为 JSON，遇到 XML 就直接报错或返回空体。关键不是“怎么接收”，而是“怎么阻止框架提前篡改原始字节流”。
-
express必须禁用bodyParser.json()和bodyParser.urlencoded()中间件，改用raw解析器：app.use(express.raw({ type: 'application/xml', limit: '1mb' })); -
fastapi要显式声明Request依赖，用await request.body()拿原始 bytes，不能写request: XMLModel这类 Pydantic 自动解析 - NGINX 或 Cloudflare 等前置代理可能默认 strip
Content-Type或强制 gzip，导致后端收到乱码——务必检查request.headers.get('content-type')是否真为application/xml或text/xml
XML 解析前先校验格式和编码，否则 xml.etree.ElementTree.parse() 会静默失败
推送方常忽略 XML 声明或用非 UTF-8 编码（比如 GB2312），Python 的 ElementTree 默认只认 UTF-8，不声明编码就抛 UnicodeDecodeError 或解析出乱码节点。
- 先用
chardet.detect()猜编码，再 decode 成字符串，比直接传 bytes 给ET.fromstring()更稳 - 用
lxml.etree.fromstring()替代标准库，它对编码容忍度高，且能捕获更细的解析错误（如XMLSyntaxError） - 必须检查根节点名是否符合预期——很多推送服务会在失败时返回 HTML 错误页（如
401 Unauthorized），不校验就直接 parse 会崩
签名验证必须在 XML 解析之后、业务逻辑之前做
不少系统（如微信支付、银联）把签名放在 HTTP Header（如 X-Signature），但签名原文是整个 XML 字符串（含换行、缩进、编码）。如果先解析再拼回字符串，格式稍有差异（比如属性顺序、空白处理）就会验签失败。
- 原始 XML 字节流（
request.body）拿到后立刻计算签名，不要经过任何 decode/encode 或 DOM 操作 - 注意 BOM 头：Windows 记事本生成的 UTF-8 XML 可能带
\ufeff，要切掉再算签 - 签名算法常用
HMAC-SHA256，密钥由平台分配，绝不能硬编码在代码里，应从环境变量或密钥管理服务读取
异步处理 XML 时别在主线程里做耗时解析或 DB 写入
WebHook 是同步 HTTP 请求，超时通常只有 3–10 秒。如果 XML 很大（比如 >500KB）、含大量嵌套节点，或后续要调第三方 API、写数据库，主线程阻塞会导致推送方重试，造成重复消费。
- 收到 XML 后立即返回
200 OK，把解析、验签、落库等动作扔进后台任务队列（如 Celery、RQ、或简单用asyncio.create_task()） - 用
lxml的iterparse()流式解析大 XML，避免一次性加载整个树到内存 - 记录原始 XML 到临时存储（如 Redis 或本地文件），便于重试时复现问题；但注意敏感字段脱敏，别把银行卡号、身份证号全存下来
真正难的不是解析 XML，而是推送方不按规范发——比如 Content-Type 写错、签名漏了换行、时间戳用的是本地时区。留一手原始 payload 日志，比写十个 if-else 判定更管用。
