基于微信网页版协议实现安全无侵入的消息防撤回与存档方案

微信防撤回消息存档Wechaty

于 2026-07-03 10:00:01 修改

·本内容遵循CC 4.0 BY-SA版权协议

1. 项目概述：为什么我们需要一个“终极”的防撤回方案？

在即时通讯软件中，撤回功能本意是修正误发消息，但在实际工作与生活中，它常常演变成一种“信息博弈”的工具。对方撤回了一条关键信息，可能是报价、承诺，或者一句不该说的话，而你只能对着“对方已撤回一条消息”的提示干瞪眼。这种信息不对等带来的困扰，相信很多人都深有体会。尤其是在一些需要留存证据或复盘沟通的正式场景，消息的完整性至关重要。

市面上的“防撤回”方案五花八门，从早年需要Root或越狱的手机插件，到各种声称能用的第三方修改版微信，再到一些复杂的抓包、Hook技术。但这些方案要么风险极高（封号、隐私泄露），要么操作繁琐、稳定性差，要么随着微信版本更新而失效。对于绝大多数非技术背景的普通用户，或者追求稳定、安全的办公族来说，一个简单、可靠、无侵入性的方案才是刚需。

今天要分享的，就是一个我称之为“终极”的方案。它不修改微信客户端，不侵入你的手机或电脑系统，完全在外部独立运行。其核心思路是：利用微信官方提供的接口（如网页版、PC端协议），建立一个消息监听与转发的中继服务，将所有收到的消息（包括被撤回的）实时、完整地保存到你自己可控的第三方平台（如本地数据库、笔记软件或另一个聊天工具）。整个过程部署简单，5分钟左右就能跑起来，一旦部署完成，就像给你的微信对话上了一道“保险”，所有流入的消息都会被永久存档。

2. 方案核心思路与架构选型

为什么说这个方案是“终极”且安全的？关键在于它的设计哲学：只读不写，旁路监听。它不向微信服务器发送任何可能触发风控的指令（如自动回复、批量操作），仅仅作为一个安静的“记录员”，接收并保存微信推送给客户端的消息流。这从根本上避免了因行为异常导致的账号风险。

2.1 技术路径对比与选型理由

实现消息监听，主要有几条技术路径：

客户端Hook/插件：直接修改微信客户端的内存或代码，拦截撤回指令。这是最早一批防撤回工具的做法。缺点：技术门槛高，需要逆向分析，每次微信更新都可能失效，且极易被检测到，封号风险最大。
协议模拟：完全模拟微信的登录和通讯协议，自己实现一个微信“机器人”。功能最强大，但复杂度也最高，需要维护复杂的登录算法和消息加密，稳定性挑战大。
官方接口利用：利用微信官方开放的、用于第三方开发的接口，如网页版微信的WebSocket协议、企业微信机器人、或微信公众平台的客服消息接口。这是目前最稳定、最安全的路径。

我们的方案选择了第三条路，具体来说是基于微信网页版的通讯协议。为什么？

稳定性：网页版是微信官方长期维护的功能，协议相对稳定，变动频率远低于客户端。
安全性：使用你自己的账号扫码登录，登录态受微信官方保护。我们的程序只作为一个“浏览器”去连接这个会话，不涉及密码，权限与你手动登录网页版微信完全一致。
跨平台：基于网络协议，部署程序可以运行在任何有网络环境的设备上，如家里的NAS、云服务器、办公室的旧电脑，不依赖特定操作系统。
无侵入：完全不影响你手机或电脑上正常微信客户端的任何功能。

2.2 系统架构设计

整个方案的架构非常清晰，包含三个核心组件：

消息采集端（Listener）：这是一个后台服务程序，核心任务是模拟微信网页版登录，并保持长连接，实时接收所有聊天消息（个人、群聊）。当收到一条消息时，它会立即判断这条消息是否是一条“撤回通知”。如果是普通消息，则直接打包；如果监测到撤回通知，它会尝试从临时缓存中找出被撤回消息的原始内容。
消息处理与存储引擎（Processor & Storage）：采集端收到消息后，将结构化数据（发送人、时间、内容、类型等）发送给处理引擎。引擎负责进行格式化、去重，并持久化存储。存储后端可以根据需求灵活选择，例如：
- SQLite/MySQL数据库：适合需要复杂查询和数据分析的场景。
- 本地文件（JSON/Markdown）：最简单，按日期或对话人生成文件，易于阅读和备份。
- 第三方笔记软件（如Obsidian、Notion）：通过API将消息同步过去，直接融入你的知识管理体系。
- 另一个聊天工具（如Telegram Bot）：将消息实时转发到你的私人Telegram频道，实现异地备份和实时提醒。
配置与管理界面（可选）：一个简单的Web页面或配置文件，用于设置要监听的特定聊天对象、设置关键词过滤、管理存储路径等。

整个数据流是单向的：微信服务器 -> 采集端 -> 处理引擎 -> 存储。你的微信账号只作为消息的接收方，程序不会以你的身份发送任何消息，这是安全性的基石。

3. 快速部署实战：5分钟搭建你的消息存档系统

理论讲完，我们进入实战环节。我将以一个基于开源项目 wechaty 的 Node.js 方案为例，因为它生态丰富，封装性好，适合快速部署。即使你没有Node.js基础，按照步骤也能完成。

3.1 基础环境准备

首先，你需要一个运行环境。推荐使用一台24小时开机的设备，如：

家用NAS（如群晖、威联通）：最佳选择，低功耗长开机。
云服务器（如腾讯云轻量应用服务器）：有公网IP，可随时随地访问。
旧电脑/树莓派：成本低，物尽其用。

我这里以一台安装了 Ubuntu 22.04 的云服务器为例。

步骤1：连接服务器并更新系统 通过SSH连接到你的服务器，执行以下命令确保系统是最新的。

BASH

ssh your_username@your_server_ip

sudo apt update && sudo apt upgrade -y

步骤2：安装Node.js运行环境 wechaty 需要Node.js环境。我们使用NodeSource仓库安装长期支持版(LTS)。

BASH

# 安装NodeSource仓库脚本

curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -

# 安装Node.js

sudo apt install -y nodejs

# 验证安装

node --version

npm --version

看到版本号输出，说明安装成功。

3.2 部署消息采集与转发机器人

我们使用一个现成的、功能集中的开源机器人框架作为基础进行修改。

步骤3：创建项目目录并初始化

BASH

mkdir wechat-archive && cd wechat-archive

npm init -y

步骤4：安装核心依赖 我们需要 wechaty 核心库，以及一个用于登录的插件 wechaty-puppet-wechat。同时安装 qrcode-terminal 用于在终端显示登录二维码，node-schedule 用于定时任务（如每日备份报告）。

BASH

npm install wechaty wechaty-puppet-wechat qrcode-terminal node-schedule

步骤5：编写核心机器人脚本 创建一个名为 bot.js 的文件，并填入以下代码。这段代码实现了登录、接收所有消息、识别撤回、并将消息保存到本地JSON文件的功能。

JAVASCRIPT

const { WechatyBuilder } = require('wechaty');

const { FileBox } = require('file-box');

const QRCode = require('qrcode-terminal');

const schedule = require('node-schedule');

const fs = require('fs').promises;

const path = require('path');

// 配置部分

const config = {

storageDir: './chat_logs', // 消息存储目录

cacheSize: 100, // 撤回消息缓存条数

};

// 确保存储目录存在

async function ensureDir(dir) {

try {

await fs.access(dir);

} catch {

await fs.mkdir(dir, { recursive: true });

}

// 消息缓存，用于处理撤回

let messageCache = new Map();

// 格式化日期

function formatDate(date = new Date()) {

return date.toISOString().replace(/T/, ' ').replace(/\..+/, '');

}

// 安全地写入文件（追加模式）

async function appendToFile(filePath, data) {

await ensureDir(path.dirname(filePath));

await fs.appendFile(filePath, JSON.stringify(data, null, 2) + ',\n', 'utf8');

}

// 主函数

async function main() {

await ensureDir(config.storageDir);

const bot = WechatyBuilder.build({

puppet: 'wechaty-puppet-wechat', // 使用网页版协议

puppetOptions: {

uos: true // 启用UOS协议，提高登录稳定性

name: 'archive-bot',

});

bot.on('scan', (qrcode, status) => {

if (status === 2) {

console.log(`请使用微信扫描二维码登录 (状态: ${status})`);

QRCode.generate(qrcode, { small: true });

}

});

bot.on('login', (user) => {

console.log(`用户 ${user.name()} 登录成功`);

const today = new Date().toISOString().split('T')[0];

console.log(`今日消息将保存至: ${path.join(config.storageDir, `${today}.json`)}`);

});

bot.on('logout', (user) => {

console.log(`用户 ${user.name()} 已登出`);

});

bot.on('message', async (msg) => {

// 1. 忽略自己发送的消息

if (msg.self()) return;

const talker = msg.talker();

const room = msg.room();

const messageType = msg.type();

const messageId = msg.id;

const timestamp = msg.date() || new Date();

let conversationName = '未知';

let conversationId = '';

if (room) {

// 群消息

conversationName = await room.topic();

conversationId = room.id;

} else {

// 私聊消息

conversationName = talker.name();

conversationId = talker.id;

}

// 基础消息对象

const baseLog = {

id: messageId,

timestamp: formatDate(timestamp),

conversationId: conversationId,

conversationName: conversationName,

senderId: talker.id,

senderName: talker.name(),

type: messageType,

};

// 2. 判断是否为撤回消息

// 网页版协议中，撤回消息通常表现为一条特殊的系统消息，文本内容包含“撤回”字样

if (messageType === bot.Message.Type.Text) {

const text = msg.text();

if (text.includes('撤回了一条消息')) {

console.log(`[撤回警报] 在 ${conversationName} 检测到撤回！`);

// 尝试从缓存中匹配被撤回的消息

// 通常撤回通知消息的id与被撤回原消息的id有某种关联，这里我们用一个简单策略：

// 假设撤回通知前一条缓存的消息就是被撤回的（实际可能更复杂，需要根据消息id模式解析）

// 这是一个简化示例。更健壮的做法是解析撤回消息中的引用id。

let recalledMsg = null;

// 这里我们简单地从缓存中查找最近一条来自同一会话、同一发送者的消息

for (let [cachedId, cachedMsg] of messageCache) {

if (cachedMsg.conversationId === conversationId && cachedMsg.senderId === talker.id) {

recalledMsg = cachedMsg;

messageCache.delete(cachedId); // 找到后从缓存移除

break;

}

const recallLog = {

...baseLog,

event: 'RECALL',

recalledContent: recalledMsg ? recalledMsg.content : '[未能捕获原文]',

originalMsgId: recalledMsg ? recalledMsg.id : 'unknown',

};

// 保存撤回记录

const recallFile = path.join(config.storageDir, `recall_${new Date().toISOString().split('T')[0]}.json`);

await appendToFile(recallFile, recallLog);

console.log(`已记录撤回事件，原文: ${recallLog.recalledContent.substring(0, 50)}...`);

return; // 撤回消息处理完毕，不再进入普通消息流程

}

// 3. 处理并保存普通消息

let content = '';

switch (messageType) {

case bot.Message.Type.Text:

content = msg.text();

break;

case bot.Message.Type.Image:

const imageFile = await msg.toFileBox();

const imageName = `${messageId}.${imageFile.name.split('.').pop() || 'jpg'}`;

const imagePath = path.join(config.storageDir, 'images', imageName);

await ensureDir(path.dirname(imagePath));

await imageFile.toFile(imagePath, true);

content = `[图片] 文件已保存: ${imagePath}`;

break;

case bot.Message.Type.Attachment:

case bot.Message.Type.Audio:

case bot.Message.Type.Video:

const fileBox = await msg.toFileBox();

const fileName = `${messageId}_${fileBox.name}`;

const filePath = path.join(config.storageDir, 'files', fileName);

await ensureDir(path.dirname(filePath));

await fileBox.toFile(filePath, true);

content = `[文件] ${fileBox.name} 已保存: ${filePath}`;

break;

default:

content = `[暂不支持的消息类型: ${messageType}]`;

}

const messageLog = {

...baseLog,

event: 'RECEIVE',

content: content,

};

// 将消息存入缓存，用于后续可能的撤回匹配

messageCache.set(messageId, {

conversationId,

senderId: talker.id,

content: content,

id: messageId,

});

// 控制缓存大小，避免内存泄漏

if (messageCache.size > config.cacheSize) {

const firstKey = messageCache.keys().next().value;

messageCache.delete(firstKey);

}

// 保存到按日期命名的JSON文件

const logFile = path.join(config.storageDir, `${new Date(timestamp).toISOString().split('T')[0]}.json`);

await appendToFile(logFile, messageLog);

// 在控制台简单输出（生产环境可关闭）

console.log(`[${formatDate(timestamp)}] ${conversationName} - ${talker.name()}: ${content.substring(0, 30)}...`);

});

bot.on('error', (error) => {

console.error('机器人发生错误:', error);

});

// 启动机器人

await bot.start();

console.log('微信消息存档机器人已启动，等待扫码登录...');

// 示例：每天凌晨3点发送一份报告（可选，需要配置推送）

// schedule.scheduleJob('0 3 * * *', async () => {

// const stats = await generateDailyStats();

// console.log('每日统计:', stats);

// // 这里可以调用推送函数，如发送邮件或Telegram消息

// });

}

// 生成每日统计（示例函数）

async function generateDailyStats() {

// 实现统计逻辑，如读取当日文件计算消息数

return { total: 100, recalls: 5 }; // 示例数据

}

main().catch(console.error);

步骤6：运行并登录 在项目目录下，运行你的机器人。

BASH

node bot.js

程序启动后，控制台会显示一个二维码。请使用你希望存档消息的微信账号（建议使用小号或备用号，避免主号风险），打开手机微信，扫描此二维码登录网页版微信。

重要提示：首次登录或长时间未登录后，可能需要手机端确认。登录成功后，机器人将保持在线，开始监听并保存所有收到的消息。

至此，一个最基础的消息存档系统就已经部署完成了。所有消息会按日期保存在 chat_logs 目录下的 .json 文件中，图片和文件也会被分别保存。撤回消息会被特殊记录在 recall_日期.json 文件中。

4. 高级配置与功能扩展

基础功能跑通后，我们可以根据需求进行增强，让它变得更实用、更强大。

4.1 精细化过滤与监听规则

你可能不想存档所有聊天，只想监控特定的工作群或关键联系人。修改 bot.on('message', ...) 事件处理函数，在开头添加过滤逻辑。

JAVASCRIPT

bot.on('message', async (msg) => {

// 忽略自己发送的消息

if (msg.self()) return;

const talker = msg.talker();

const room = msg.room();

let conversationName = '';

if (room) {

conversationName = await room.topic();

// 示例：只监听名为“项目攻坚组”和“董事会”的群

const targetGroups = ['项目攻坚组', '董事会'];

if (!targetGroups.includes(conversationName)) {

return; // 非目标群，忽略

}

} else {

conversationName = talker.name();

// 示例：只监听特定联系人，如“老板”和“客户张总”

const targetContacts = ['老板', '客户张总'];

if (!targetContacts.includes(conversationName)) {

return; // 非目标联系人，忽略

}

// ... 原有的消息处理逻辑

});

4.2 消息实时推送与多端备份

仅仅本地保存还不够，我们需要实时感知。可以将重要消息实时推送到其他平台。

方案A：推送到Telegram Bot

在Telegram上找 @BotFather 创建一个新的Bot，获得一个 API Token。
安装Node.js的Telegraf库：npm install telegraf。
在 bot.js 中集成：

JAVASCRIPT

const { Telegraf } = require('telegraf');

const telegramBot = new Telegraf('你的Telegram_Bot_API_TOKEN');

const YOUR_TELEGRAM_USER_ID = 你的用户ID; // 可以从 @userinfobot 获取

// 在收到重要消息时调用

async function pushToTelegram(logEntry) {

const text = `💬 来自 ${logEntry.conversationName}\n👤 ${logEntry.senderName}\n⏰ ${logEntry.timestamp}\n📝 ${logEntry.content}`;

try {

await telegramBot.telegram.sendMessage(YOUR_TELEGRAM_USER_ID, text);

} catch (e) {

console.error('Telegram推送失败:', e);

}

// 然后在处理消息的逻辑中，对特定条件（如包含关键词“合同”、“报价”）的消息调用 pushToTelegram

方案B：保存到Notion数据库

在Notion中创建一个数据库，设计好属性（如会话、发送人、时间、内容）。
获取Notion的 API Key 和 Database ID。
安装官方SDK：npm install @notionhq/client。
编写写入Notion的函数。

这样，你就能在手机通知栏（Telegram）或你的知识库（Notion）里实时看到关键消息了。

4.3 提升稳定性：进程守护与自动重启

服务器程序可能因为网络波动或未知错误退出。我们需要一个“守护者”来确保它始终运行。

使用PM2（推荐） PM2是一个专业的Node.js进程管理工具。

BASH

# 全局安装PM2

sudo npm install -g pm2

# 使用PM2启动你的机器人，并命名为 wechat-archive

pm2 start bot.js --name wechat-archive

# 设置开机自启

pm2 startup

pm2 save

现在，即使服务器重启，你的机器人也会自动运行。常用命令：

pm2 status：查看状态
pm2 logs wechat-archive：查看实时日志
pm2 restart wechat-archive：重启应用

4.4 数据管理与定期备份

存档数据会越来越多，需要管理。

日志轮转：可以修改脚本，每月或每年自动归档旧日志文件。
数据库存储：对于消息量大的场景，建议将存储后端从文件切换到数据库（如SQLite或MySQL）。这需要修改 appendToFile 函数，改为执行SQL插入操作。数据库便于查询和统计，例如：“找出上周所有包含‘合同’关键词的消息”。
异地备份：定期将 chat_logs 目录同步到网盘（如通过rclone同步到Google Drive）或另一台服务器，实现容灾。

5. 常见问题、风险与排查指南

在实际部署和长期使用中，你可能会遇到以下问题。这里是我踩过坑后总结的排查思路。

5.1 登录与连接问题

问题1：扫码后提示“登录环境异常”或无法登录。

原因与解决：微信对网页版登录的风控加强。尝试以下方法：
1. 更换Puppet：wechaty-puppet-wechat 使用的是网页版协议。可以尝试其他协议实现的Puppet，如 wechaty-puppet-padlocal（需付费购买token，但更稳定）或 wechaty-puppet-service（官方服务）。
2. 启用UOS协议：代码中已设置 uos: true，这是专门为第三方客户端设计的协议，稳定性更高。确保它已启用。
3. 使用“小号”：强烈建议使用一个不重要的、实名信息较少的微信账号作为机器人账号。主号频繁在非官方客户端登录风险较高。
4. 环境隔离：如果服务器IP被微信拉黑，尝试更换服务器IP（云服务器可换弹性公网IP）。

问题2：机器人运行一段时间后自动掉线。

原因与解决：网页版登录态过期或网络中断。
1. 实现断线重连：在 bot.on('logout') 事件中，编写逻辑重新初始化并启动bot。但要注意频率，避免短时间频繁重连。
2. 使用PM2守护：如前所述，PM2可以在进程退出时自动重启。结合下面的心跳检测更佳。
3. 增加心跳检测：定时（如每30分钟）让机器人给自己文件传输助手发一条无关紧要的消息（需谨慎，有风险），或检查登录状态，以保持会话活跃。

5.2 消息处理与撤回识别问题

问题3：无法准确捕获被撤回的原文。

原因：示例代码中的撤回匹配逻辑是简化的。微信的撤回通知消息体结构可能不直接包含原消息ID。
深入解决：
1. 深入解析消息XML：微信的许多系统消息（如撤回、红包、转账）是以XML格式传递的。你需要解析 msg.text() 中的XML字符串，提取 revokemsg 节点下的 msgid，这个才是被撤回消息的唯一ID。然后根据这个ID去你的缓存里查找。
2. 增强缓存策略：缓存不应只存最近100条。可以为每个会话单独维护一个更大的缓存（如Map套Map），并定期清理过期消息。
3. 使用更底层的Puppet：一些付费的Puppet服务（如PadLocal）可能提供了更直接的撤回事件回调，能直接拿到被撤回消息的内容。

问题4：图片、文件等媒体消息保存失败或乱码。

原因：网络超时或存储权限问题。
解决：
1. 增加重试机制：在 toFile() 保存文件时，用 try-catch 包裹，失败后重试2-3次。
2. 检查磁盘空间与权限：确保运行程序的用户对 storageDir 目录有读写权限。
3. 分类型存储：如示例代码所示，将图片、文件、语音分目录存放，避免单个目录文件过多。

5.3 安全与隐私风险规避

问题5：使用此方案会被封号吗？

风险评估：任何非官方的自动化行为都有风险。但本方案通过 “只读不写” 将风险降至最低。它模拟的是一个“只接收、不发送”的静默客户端，这与恶意营销、群发广告、频繁拉人等高风险行为有本质区别。我使用备用号稳定运行超过一年，未出现封号。但绝对不能保证100%安全。
风险规避黄金法则：
1. 使用专用小号：绝对不要用你的主微信号、工作号或绑定了重要金融服务的账号。
2. 禁止发送消息：不要在机器人代码中添加任何主动发送消息的逻辑（如自动回复、关键词触发回复）。这是最大的风险点。
3. 控制登录频率：避免频繁登录、登出。保持一个稳定的在线状态。
4. 数据加密存储：保存聊天记录的服务器要做好安全防护，数据库或文件最好加密，防止服务器被入侵导致聊天记录泄露。

问题6：如何保护存档的聊天记录？

存储端加密：可以使用 crypto-js 等库，在写入文件前对消息内容进行对称加密（如AES），读取时再解密。密钥由你自己保管。
访问控制：如果你的存档服务有Web管理界面，务必设置强密码，或仅允许内网访问。
定期清理：制定数据保留策略，例如只保留最近一年的详细记录，更早的数据可以只保留统计摘要或进行脱敏归档。

5.4 性能与维护

问题7：消息量很大，程序卡顿或内存占用高。

优化方向：
1. 消息队列异步处理：收到消息后，不立即进行耗时的文件写入或网络推送，而是放入一个内存队列（如数组），由另一个独立的线程或定时任务批量处理。可以使用 bull 或 bee-queue 等库。
2. 切换数据库：当单日消息量上万时，频繁的JSON文件追加写入效率会变低。应迁移到SQLite或MySQL，利用数据库的事务和索引优化性能。
3. 优化缓存：精确控制 messageCache 的大小和淘汰策略，避免内存无限增长。

问题8：如何监控机器人的运行状态？

健康检查接口：在代码中添加一个简单的HTTP服务器，暴露一个 /health 接口，返回机器人的运行状态、登录状态、最近消息时间等。
外部监控：使用UptimeRobot等网站监控服务，定期访问你的健康检查接口。如果连续失败，则通过邮件、短信告警。
日志聚合：将程序的日志（console.log）不仅输出到本地文件，也发送到像 winston 这样的日志库，并配置日志轮转和日志级别（DEBUG, INFO, ERROR）。

部署并稳定运行这套系统后，你就拥有了一个完全自主可控的微信消息“黑匣子”。它静静地运行在后台，忠实记录着每一个重要的对话瞬间。无论是用于工作留痕、知识沉淀，还是单纯满足“好奇心”，它都提供了一个安全、可靠的技术解决方案。技术是为需求服务的，请务必在合法合规、尊重他人隐私的前提下使用它。