wechaty 维护放缓、itchat 失效后，个人微信机器人怎么做

前言

如果你在 2020 年前后开始折腾个人微信机器人，大概率用过这两个库：itchat 和 wechaty。那时候用微信网页版协议，几十行 Python 就能让微信自动回复消息、拉群、转发图片，体验很丝滑。

然而近几年情况发生了根本性变化。微信官方逐步关闭了网页版协议的登录入口，itchat 赖以运作的 web.wechat.com 接口对大量账号不再可用——新注册账号几乎全部无法登录网页版，老账号也越来越多地被限制。itchat 的 GitHub 仓库自 2019 年后几乎没有实质性维护，Issue 里堆满了"扫码闪退""登录后立刻掉线"的报告，作者已无力修复根本原因。

wechaty 的情况稍好一些，但也面临相似困境。wechaty 本身是一个多协议聚合框架，核心思路是通过"Puppet"插件对接不同的底层实现。早期免费的 puppet-wechat（网页版协议）同样受微信封锁影响，可用性大幅下滑；付费的商业 puppet（如 iPad 协议、Mac 协议）虽然相对稳定，但授权费用不低，且 wechaty 主仓库的更新节奏明显放缓，部分 API 在新版本中存在兼容性问题。

这篇文章梳理现阶段的几条可行路径，并给出各方案的实际对比，帮助你在 2024–2025 年重新选型。

一、先搞清楚：为什么这两个库会失效

1.1 itchat 失效的根本原因

itchat 依赖微信网页版登录协议（login.weixin.qq.com + web.wechat.com）。这套协议并非官方开放 API，而是研究者通过抓包还原的私有接口。

微信自 2017 年起陆续对网页版收紧，原因包括：

网页版接口被大量用于营销群发、骚扰，投诉率高
无法有效做账号安全管控
微信战略重心已不在网页端

到 2021–2022 年，大部分新号已无法登录网页版。itchat 无法绕过这一限制，因为问题出在微信服务端的账号策略上，不是客户端代码能解决的。

1.2 wechaty 为何维护放缓

wechaty 是个框架层，它本身没有协议实现，必须搭配 puppet。社区维护的免费 puppet 普遍遇到以下问题：

Puppet 类型	底层协议	现状
puppet-wechat	网页版	与 itchat 同命运，大量账号不可用
puppet-wxwork	企业微信	个人号不适用
puppet-padlocal	iPad 协议	商业授权，免费名额极少
puppet-xp	PC Hook	依赖特定 Windows + 微信版本，不稳定

框架本体的 TypeScript 代码虽然质量不错，但在"可用 puppet"断货的情况下，更新框架本身意义有限，维护动力自然下降。

二、现阶段的几条可行路径

2.1 路径 A：基于 Hook 的 PC 端方案（gewechat 等）

Hook 方案不走网页版协议，而是在 Windows 本地注入 DLL 拦截微信进程的内部调用，直接读写消息数据。代表项目包括 gewechat。

优点：

不依赖网页版，理论上只要 PC 微信可登录就可用
功能覆盖广：消息收发、联系人管理、群操作基本都能做
有现成的 HTTP 接口封装，不需要自己写注入逻辑

缺点：

必须运行在 Windows 系统，且微信版本必须固定——微信一更新，注入逻辑可能立刻失效，需要等项目维护者适配
只能单机运行，无法容器化部署（微信不支持无头模式）
长期稳定性存疑：微信可能随时加固安全机制

适用场景： 企业内网、有专用 Windows 机器、能接受手动维护版本的场景。

2.2 路径 B：iPad/Mac 协议 API（托管方案）

这类方案将协议层做成服务，开发者通过 HTTP 接口调用，不需要自己维护协议细节。

典型架构：

你的业务代码
    ↓ HTTP POST
接口服务（托管协议层）
    ↓ 模拟 iPad/Mac 客户端
微信服务器

这条路的核心优势是解耦：协议维护交给专门的团队，你只需关注业务逻辑。遇到微信更新，只需等接口服务更新，自己的代码几乎不用动。

WechatApi 提供扫码登录、消息收发、好友与群管理等 REST 接口，HTTP 调用即可，开发者无需维护底层协议。

缺点： 需要信任第三方服务的稳定性和隐私策略；有调用频率限制；需要付费。

适用场景： 快速上线、没有专职运维、业务重心在上层逻辑的个人开发者和小团队。

2.3 路径 C：企业微信（官方渠道）

如果你的需求可以转化到企业微信场景，这是唯一的官方合规路径。微信官方提供企业微信开放平台 API，稳定、有 SLA、功能覆盖内部沟通场景。

适用场景： 内部通知机器人、OA 集成、员工消息推送。

不适用： 需要操作个人微信账号、管理个人微信好友/群的场景。

三、各方案对比

维度	itchat / wechaty 网页版	PC Hook（gewechat）	托管 HTTP API	企业微信官方 API
可用性（2025）	大部分账号不可用	可用，但版本敏感	可用	可用
运维成本	低（已无需维护，因为不可用）	高（需锁版本、手动更新）	低	低
部署环境	任意	仅 Windows	任意（调 HTTP）	任意
个人号支持	是（但失效）	是	是	否
开源免费	是	部分开源	通常付费	免费（官方）
长期稳定性	差	中	依赖服务商	高

四、迁移指南：从 itchat 切换到 HTTP API

如果你原来用 itchat 写了一个消息监听+自动回复的机器人，下面演示如何用 HTTP API 方案重构核心逻辑。

4.1 原 itchat 代码结构（仅供参考，现已不可用）

python# 原 itchat 写法（2019 年前可用，现已失效）
import itchat

@itchat.msg_register(itchat.content.TEXT)
def handle_text(msg):
    if "你好" in msg['Content']:
        itchat.send("你好！", toUserName=msg['FromUserName'])

itchat.auto_login()
itchat.run()

这段代码依赖网页版登录，现在扫码后会立即报错或掉线。

4.2 用 HTTP API 重构

新方案分两部分：主动发消息 用 POST 接口，被动收消息 用回调（Webhook）。

第一步：配置基础参数

python# 代码为示例，具体接口地址/字段名以官方文档为准
import requests

BASE  = "https://你的接口域名"   # 注册后在官方文档获取
TOKEN = "你的Token"
APPID = "你的appId"              # 扫码登录后得到
HEADERS = {"token": TOKEN}       # 鉴权字段名以官方文档为准

第二步：发送文本消息

pythondef send_text(to_wxid: str, content: str) -> bool:
    """
    发送文本消息
    :param to_wxid: 收件人的微信ID（好友或群ID）
    :param content: 消息内容
    """
    url = f"{BASE}/message/postText"
    payload = {
        "appId": APPID,
        "toWxid": to_wxid,
        "content": content
    }
    resp = requests.post(url, json=payload, headers=HEADERS, timeout=10)
    data = resp.json()
    # ret==200 表示成功，具体字段以官方文档为准
    return data.get("ret") == 200

第三步：配置消息回调（接收消息）

HTTP API 方案接收消息靠回调：平台把收到的消息 POST 到你指定的地址。你需要有一个公网可访问的 HTTP 服务。

python# 用 Flask 搭建回调服务
from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/wechat/callback", methods=["POST"])
def callback():
    msg = request.json
    # 字段名以官方文档为准，下面是示例结构
    from_wxid = msg.get("fromWxid", "")
    content    = msg.get("content", "")
    msg_type   = msg.get("type", 0)

    # 文本消息类型（type 值以文档为准）
    if msg_type == 1 and "你好" in content:
        send_text(from_wxid, "你好！有什么可以帮你？")

    # 必须返回 HTTP 200，否则平台会重试
    return jsonify({"code": 200})

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

第四步：注册回调地址

pythondef set_callback(callback_url: str) -> bool:
    """
    设置消息回调地址，公网可达才能收到消息
    """
    url = f"{BASE}/setCallback"
    payload = {
        "appId": APPID,
        "callbackUrl": callback_url
    }
    resp = requests.post(url, json=payload, headers=HEADERS, timeout=10)
    return resp.json().get("ret") == 200

# 示例：你的服务部署在公网
set_callback("https://your-server.example.com/wechat/callback")

4.3 关键注意事项

回调必须公网可达：本地开发时可用 ngrok 做内网穿透临时测试，生产环境必须部署到有公网 IP 的服务器。
回调返回 HTTP 200：如果你的处理函数抛异常导致非 200 响应，平台会认为投递失败并重试，可能造成重复处理。
主动发的消息不会触发自己的回调：只有对方发来的消息才会推送给你。
频率控制：批量发消息要加随机间隔（建议 3–10 秒），避免因频率过高导致接口返回失败或账号异常。

五、常见排查问题

5.1 配置完回调后收不到消息

按以下顺序排查：

确认微信账号在线：登录状态断开后，回调自然不会有数据
确认回调地址公网可达：用 curl 从外网测试你的回调 URL 是否能返回 200
确认地址已正确注册：调用 setCallback 接口后检查返回值是否成功
注意主动发消息无回调：只有收到对方消息时才推送

5.2 接口返回失败（ret ≠ 200）

常见原因：

账号刚登录，在线时间不足（建议新号在线 3 天后再大量调用）
单位时间调用频率过高
消息内容触发微信内容过滤（含敏感词、外链等）

总结

itchat 和 wechaty 网页版协议的时代已经基本结束，现在维护个人微信机器人需要换一条路：要么接受 PC Hook 方案的高运维成本，要么转向 HTTP API 托管方案专注业务逻辑，要么在条件允许时迁移到企业微信官方渠道。没有完美的选择，只有适合当前场景的选择。