做微信机器人最崩溃的是"机器人不工作了但没报错"，完全不知道代码跑到哪一步停了。调试核心就是让执行过程可见。下面按调试信息输出方式，拆解四种通用思路。

四种调试思路

思路 1：日志埋点调试

让代码每走一步打一条日志，形成完整流水账。埋点覆盖：Webhook 入口打请求、解析字段打结果、调 Eyun 接口前打参数、调完打响应 code、处理完打结果。每条日志带 request_id（用 msgId），一条消息的日志能串成一线。Eyun 的错误码（1000成功/1001Token无效/1002wId不存在/1004参数错误）是日志判断依据，看到 1004 直接查参数。

思路 2：断点调试

IDE 打断点，代码跑到断点就停住看变量。做法：本地 IDE 在回调入口、sendText 处打断点，Postman 发构造的 POST 模拟回调事件。暂停后逐个检查：fromUser 对不对、content 值对不对、sendText 三个参数组对了没。按照 Eyun 开发文档 的规范，sendText 传 wId、toUser、content 三个必填参数，断点时逐个核对即可。

思路 3：模拟请求调试（Mock）

每次调真实接口耗配额还限频，测试消息多了骚扰用户。Mock 思路就是写 mock 层，把真实的 Eyun 接口调用替换成假返回：sendText 的 mock 直接返回 {code:1000} 不发真消息，Webhook 回调不用等推送，自己用 Postman 构造 JSON 往本地发。开发阶段 90% 逻辑可以 mock 跑通，联调才切真实接口。

思路 4：流量重放调试

线上 Bug 本地复现不了，就把线上事故现场的原始请求原封不动重跑一遍。做法：从日志复制出问题那次 Webhook 回调的原始 JSON（连 msgId 都别改），用 curl/Postman POST 到本地，配合日志或断点排查。保留 msgId 是为了幂等，避免重放产生重复。Eyun 的 Webhook 回调是标准 RESTful JSON，直接从日志复制就能用。

四种思路对比表

统一调试框架示例

import json, logging, functools as ft
logging.basicConfig(level=logging.INFO,
    format="%(asctime)s|%(rid)s|%(step)s|%(message)s")
LOG, MOCK = logging.getLogger("eyun"), True
def log_step(step):
    def dec(fn):
        @ft.wraps(fn)
        def w(p, *a, **kw):
            rid = p.get("msgId", "?")
            LOG.info("recv %s", json.dumps(p, ensure_ascii=False)[:200],
                     extra={"rid":rid,"step":step+".in"})
            r = fn(p, *a, **kw)
            LOG.info("ret=%s", r, extra={"rid":rid,"step":step+".out"})
            return r
        return w
    return dec
def send_text(w_id, to, c):
    p = {"wId":w_id,"toUser":to,"content":c}
    LOG.info("p=%s", p, extra={"rid":to,"step":"send.req"})
    r = {"code":1000} if MOCK else __real_call(p)
    LOG.info("c=%s", r.get("code"), extra={"rid":to,"step":"send.resp"})
    return r
@log_step("webhook")
def webhook(p):
    if p.get("msgType") == "text":
        send_text(p["wId"], p["fromUser"], "echo:"+p["content"])
    return {"code": 0}

写在最后

四种调试从"最省工具"到"最精准"递进：日志最省、断点最准、Mock最快、重放最真。实际项目混合用：开发期 Mock+断点，线上出问题日志+重放定位。调试心法：执行过程可见=问题好修一半。接口参数、回调字段、错误码和重试规则参考 Eyun 开发文档，落地建议团队统一日志格式和 request_id 规范，排查跨服务问题时顺着同一套流水账查到底，接口完整定义见 Eyun 平台 文档中心。