1. 项目概述：为什么我们需要“防撤回”？

在即时通讯软件深度融入我们工作和生活的今天，微信和QQ的“消息撤回”功能，就像一把双刃剑。一方面，它确实为发送者提供了纠错的机会，避免了因手滑或误发带来的尴尬；但另一方面，对于接收者而言，一条“对方已撤回一条消息”的提示，常常伴随着强烈的好奇心、信息缺失的焦虑，甚至可能错失关键的工作指令或重要信息。尤其是在PC端，我们处理的信息量更大、场景更正式，一条被撤回的消息背后，可能是一个未确认的需求、一个临时的修改意见，或者一次重要的沟通记录。

因此，“PC端微信QQ防撤回神器”这个项目，其核心价值并非鼓励窥探隐私，而是旨在为信息接收方提供一个“知情权”的备份方案。它解决的是一种普遍存在的“信息不对称”焦虑，让用户在对方选择撤回时，依然能保留一份完整的沟通上下文，确保工作流不被打断，重要信息不被遗漏。这更像是一个为自己信息环境增加“冗余备份”的工具，尤其适合需要严格留存沟通记录的自由职业者、项目管理者、客服人员以及对信息完整性有较高要求的用户。

从技术角度看，实现防撤回，本质上是对官方客户端进行一种“功能增强”。它不是破解，也不是外挂，而是利用了客户端软件在本地处理消息的机制。当消息从服务器抵达你的电脑并被客户端渲染到聊天窗口时，它已经存在于你电脑的内存或临时存储中了。撤回指令更像是一个“删除视图”的命令，而我们的目标，就是在这个删除动作发生之前，把消息内容“拦截”并保存下来。接下来，我将从设计思路、技术实现、具体操作到避坑指南，完整拆解如何构建这样一个工具。

2. 核心原理与方案选型：拦截的“艺术”

要实现防撤回，首先得明白消息在客户端是如何“流动”的。无论是微信还是QQ，其PC客户端都是一个典型的C/S架构应用，但大部分消息渲染和界面交互逻辑都在本地完成。

2.1 消息的生命周期与撤回时机

一条消息从发送到被对方接收并可能撤回，大致经历以下阶段：

1. 发送端加密并发出 ：消息内容经过加密后，发送到腾讯的服务器。
2. 服务器中转 ：服务器进行推送。
3. 接收端客户端接收与解密 ：你的PC客户端收到数据包，在内存中解密，得到明文消息。
4. 本地渲染与展示 ：客户端调用其UI框架（对于Windows版，早期是IE内核，现在多为自研或Chromium Embedded Framework）的API，将消息文本、图片等信息绘制到聊天窗口的特定区域。
5. 撤回指令抵达 ：当对方发起撤回时，服务器会向你的客户端发送一个特殊的“撤回指令”数据包。
6. 客户端执行撤回 ：你的客户端收到指令后，会定位到那条消息在本地内存和UI视图中的位置，然后执行一系列操作：移除聊天窗口中的该消息气泡，替换为“对方已撤回一条消息”的提示，并可能尝试清理相关的本地缓存数据。

防撤回的关键，就在于 第4步与第6步之间 。我们需要在消息被完美渲染到界面之后、撤回指令生效之前，将消息内容持久化保存下来。有几种主流的技术思路：

2.2 主流技术方案对比

方案类型	实现原理	优点	缺点	适用场景
内存Hook/注入	通过DLL注入、API Hook等技术，拦截客户端创建消息UI控件、设置文本内容的函数调用（如 SetWindowTextW , 各种UI框架的文本设置方法）。	拦截精准，时效性高，几乎与消息显示同步。功能强大，可获取丰富上下文。	技术门槛高，涉及逆向分析。易触发客户端安全检测，导致封号风险。稳定性依赖客户端版本，更新后易失效。	追求极致效果、有深厚逆向经验的开发者。
窗口消息钩子	利用Windows的 SetWindowsHookEx 监听特定窗口（聊天窗口）的 WM_PAINT （绘制）、 WM_SETTEXT 等消息。	相对内存Hook更“温和”，利用系统机制，部分实现较简单。	不够底层，可能错过某些动态生成的UI内容。同样需要针对性的窗口类名和消息分析。	对特定版本客户端进行快速原型验证。
网络流量分析	抓取客户端与服务器通信的Socket数据包，解密协议，从中直接提取消息内容和撤回指令。	理论上最根本，不受客户端UI变化影响。	难度极高，协议通常加密且频繁变更。需要处理TCP流重组、解密算法逆向等复杂问题。	大型安全研究，非个人开发者常规选择。
自动化脚本/辅助工具	使用自动化工具（如AutoHotkey, Python的 pyautogui ）监控聊天窗口特定区域像素变化或文本内容，定期截图或读取控件文本。	实现简单，完全外部操作，零侵入，理论上最安全。	可靠性差，容易受窗口遮挡、分辨率变化、客户端更新UI布局影响。效率低，有延迟。	临时性、低频率的需求，或作为补充方案。
修改客户端资源文件	早期有通过反编译客户端，修改其提示“已撤回”的字符串资源或相关逻辑代码的方法。	一旦成功，效果稳定。	操作复杂，每次客户端升级都需重新修改。篡改客户端文件本身风险极大，极易被检测封号。	极其不推荐 ，已基本被淘汰。

注意 ：任何试图修改官方客户端文件、注入代码或大规模自动化模拟操作的行为，都可能违反软件用户协议，存在账号安全风险。本系列讨论侧重于技术原理学习与交流，请务必在合规的测试环境中进行，谨慎评估个人使用风险。

综合考量 安全性、实现难度、可持续性 ，对于大多数希望自主实现或理解其原理的开发者而言，一种折中且相对可行的思路是： 基于内存扫描与文本提取的“温和型”方案 。它不主动注入代码，而是定期读取聊天窗口控件内的文本内容，通过对比变化来发现新消息和被替换的“已撤回”提示，从而还原消息。虽然这不是实时拦截，但延迟通常在数秒内，且安全性更高。下文将主要围绕这种思路展开。

3. 实战构建：基于Python的“温和型”防撤回助手

我们将使用Python作为主要语言，因为它生态丰富，适合快速开发原型。核心思路是：获取微信/QQ聊天窗口句柄 -> 遍历其子控件 -> 定位消息显示区域 -> 定时获取文本 -> 比对并保存疑似被撤回的消息。

3.1 环境准备与工具选型

首先，需要安装必要的Python库：

pip install pywin32 psutil pillow opencv-python-headless

• pywin32 : 这是核心，用于调用Windows API，实现窗口查找、控件遍历和文本获取。
• psutil : 用于更优雅地查找微信/QQ的进程。
• PIL / Pillow 和 opencv-python : 备用方案。如果纯文本获取失败，可以考虑通过截图OCR来识别消息，但这是下策，效率低。

我们需要了解目标窗口的结构。以微信PC版（版本3.9以上）为例，其主窗口类名通常是 WeChatMainWndForPC ，聊天消息区域是一个复杂的自定义控件，没有标准的控件类名（如 Edit ）。直接通过 FindWindowEx 遍历标准控件可能找不到。这时，一个更通用的方法是：先找到主窗口，然后找到聊天消息列表所在的 矩形区域 。

3.2 核心代码实现：定位与监听

第一步，找到微信进程和主窗口。

import win32gui
import win32process
import psutil
import time

def find_wechat_window():
    """查找微信PC版主窗口"""
    def callback(hwnd, windows):
        if win32gui.IsWindowVisible(hwnd) and win32gui.IsWindowEnabled(hwnd):
            window_text = win32gui.GetWindowText(hwnd)
            # 微信主窗口标题通常包含“微信”二字，且不是其他弹窗
            if "微信" in window_text and len(window_text) > 2:
                # 进一步通过进程名确认
                _, pid = win32process.GetWindowThreadProcessId(hwnd)
                try:
                    p = psutil.Process(pid)
                    if p.name().lower() == 'wechat.exe':
                        windows.append((hwnd, window_text))
                except (psutil.NoSuchProcess, psutil.AccessDenied):
                    pass
        return True

    windows = []
    win32gui.EnumWindows(callback, windows)
    # 可能有多个窗口，返回第一个（通常是主窗口）
    return windows[0][0] if windows else None

第二步，定位聊天消息区域。这步最棘手，因为微信的UI是自绘的。一个实践方法是：利用微信窗口的客户区坐标，通过经验或工具（如 spy++ ）确定消息列表的大致相对位置。

def get_chat_area_rect(hwnd):
    """获取聊天消息区域的矩形坐标（需要根据实际微信版本调整）"""
    # 先获取整个窗口客户区的位置
    left, top, right, bottom = win32gui.GetClientRect(hwnd)
    # 将客户区坐标转换为屏幕坐标
    left, top = win32gui.ClientToScreen(hwnd, (left, top))
    right, bottom = win32gui.ClientToScreen(hwnd, (right, bottom))

    # **关键：这里需要根据你的微信版本手动调整偏移量**
    # 例如，消息区域可能在客户区顶部工具栏和底部输入框之间
    # 假设工具栏高约100像素，输入框高约150像素
    tool_bar_height = 100
    input_area_height = 150
    chat_top = top + tool_bar_height
    chat_bottom = bottom - input_area_height
    chat_left = left + 10  # 左边有些许边距
    chat_right = right - 10 # 右边有些许边距

    return (chat_left, chat_top, chat_right, chat_bottom)

实操心得 ：这个偏移量 tool_bar_height 和 input_area_height 是 变量 ，会因微信版本、DPI缩放设置、窗口大小而变化。最可靠的方法是使用 PrintWindow API对整个窗口截图，然后用OpenCV模板匹配或特征匹配，找到“消息气泡”的起始位置，但这更复杂。初期可以手动调整，并记录下对你当前窗口有效的值。

第三步，定时抓取区域文本。由于无法直接获取自绘控件的文本，我们采用“截图+OCR”的降级方案，或尝试读取可能存在的无障碍文本接口（但微信通常不支持）。这里展示OCR方案（需安装 pytesseract 和Tesseract-OCR引擎）。

import win32ui
from PIL import Image
import pytesseract # 需要额外安装和配置Tesseract

def capture_and_ocr(hwnd, rect):
    """对指定矩形区域截图并进行OCR识别"""
    left, top, right, bottom = rect
    width = right - left
    height = bottom - top

    # 创建设备上下文
    hwndDC = win32gui.GetWindowDC(hwnd)
    mfcDC = win32ui.CreateDCFromHandle(hwndDC)
    saveDC = mfcDC.CreateCompatibleDC()

    # 创建位图对象
    saveBitMap = win32ui.CreateBitmap()
    saveBitMap.CreateCompatibleBitmap(mfcDC, width, height)
    saveDC.SelectObject(saveBitMap)

    # 截图
    saveDC.BitBlt((0, 0), (width, height), mfcDC, (left, top), win32con.SRCCOPY)
    saveBitMap.SaveBitmapFile(saveDC, 'temp_capture.bmp')

    # 释放资源
    win32gui.DeleteObject(saveBitMap.GetHandle())
    saveDC.DeleteDC()
    mfcDC.DeleteDC()
    win32gui.ReleaseDC(hwnd, hwndDC)

    # 使用PIL打开并OCR
    image = Image.open('temp_capture.bmp')
    # 可以对图像进行预处理，如灰度化、二值化，提高OCR精度
    # image = image.convert('L')  # 灰度
    # 根据微信聊天背景色调整二值化阈值
    # ...
    text = pytesseract.image_to_string(image, lang='chi_sim+eng') # 中英文识别
    return text

第四步，消息比对与撤回判断。这是逻辑核心。我们需要维护一个“上一次”的消息快照，与“当前次”的快照进行比对。

class RecallMonitor:
    def __init__(self):
        self.last_message_snapshot = "" # 存储上一次捕获的完整文本
        self.message_history = [] # 存储历史消息，用于比对
        self.recall_log = [] # 存储检测到的撤回消息

    def monitor_cycle(self, wechat_hwnd, chat_rect):
        current_text = capture_and_ocr(wechat_hwnd, chat_rect)
        if not self.last_message_snapshot:
            self.last_message_snapshot = current_text
            return

        # 简单的按行分割比对（实际中需要更精细的解析，如按消息气泡）
        last_lines = self.last_message_snapshot.split('\n')
        current_lines = current_text.split('\n')

        # 找出在上一轮存在，但在这一轮消失的行（可能被撤回）
        missing_lines = set(last_lines) - set(current_lines)
        for line in missing_lines:
            line_clean = line.strip()
            if line_clean and "已撤回" not in line_clean: # 避免把“已撤回”提示本身当作被撤回消息
                # 进一步判断：这条消失的行，是否在更早的历史中出现过？
                # 如果是刚刚出现的新消息又立刻消失，很可能是撤回。
                if any(line_clean in hist for hist in self.message_history[-5:]): # 检查最近5条历史
                    print(f"[疑似撤回] {time.strftime('%Y-%m-%d %H:%M:%S')}: {line_clean}")
                    self.recall_log.append((time.time(), line_clean))
                    # 可以在这里触发通知，如播放声音、写入文件等
                    with open('recall_log.txt', 'a', encoding='utf-8') as f:
                        f.write(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] {line_clean}\n")

        # 更新快照和历史
        self.last_message_snapshot = current_text
        # 只保留有意义的非空行到历史记录
        meaningful_lines = [ln.strip() for ln in current_lines if ln.strip() and "已撤回" not in ln]
        self.message_history.extend(meaningful_lines)
        # 保持历史记录长度，防止内存无限增长
        if len(self.message_history) > 100:
            self.message_history = self.message_history[-100:]

# 主循环
def main():
    monitor = RecallMonitor()
    while True:
        hwnd = find_wechat_window()
        if hwnd:
            chat_rect = get_chat_area_rect(hwnd)
            monitor.monitor_cycle(hwnd, chat_rect)
        time.sleep(3) # 每3秒检查一次，可根据需要调整

if __name__ == '__main__':
    main()

这个方案是一个基础框架，它有很多局限性，但清晰地阐述了“温和型”防撤回的核心逻辑： 定期采样 -> 差异比对 -> 逻辑判断 。它的优势是完全外部，不触碰微信进程内存，相对安全。劣势是OCR识别精度、窗口定位稳定性、以及无法处理图片/表情撤回等。

4. 高级实现与优化方向

上述基础方案离“神器”还有距离。要提升实用性，需要从以下几个方向深入：

4.1 精准控件文本提取（绕过OCR）

OCR是性能瓶颈和误差源。理想情况是能像读取记事本内容一样直接读取聊天框文本。这需要更深入的逆向分析。

• 工具辅助 ：使用 Spy++ 或 Microsoft Inspect 等工具，查看微信窗口的UI自动化树（UI Automation Tree）。新版本的客户端可能对标准控件做了封装，但或许会暴露一些可访问的文本属性。
• 内存模式搜索 ：这是更高级的方法。通过Cheat Engine等工具，在微信进程内存中搜索当前显示在屏幕上的某条特定消息的Unicode字符串。找到地址后，分析其访问和写入该地址的代码，定位到负责渲染消息的函数。然后可以用Python的 ctypes 或 pymem 等库，直接读取该内存区域。这种方法实时性极高，但需要深厚的逆向功底，且每次微信更新都可能偏移。

4.2 处理图片、文件与表情撤回

纯文本方案是片面的。撤回的可能是截图、文件或表情。

• 图片/文件 ：这类内容在显示时，通常已经在本地缓存目录生成了临时文件。微信的缓存目录通常位于 C:\Users\[用户名]\Documents\WeChat Files\[微信号]\FileStorage 下的 Image 、 File 等文件夹。可以监控这些目录的文件变化（如使用 watchdog 库）。当检测到新文件创建，并随后短时间内聊天窗口出现“已撤回”提示时，可以将该文件复制到安全位置保存。难点在于建立“文件”与“消息”的对应关系。
• 表情 ：表情多为在线资源或本地固定资源，撤回后通常无法再访问。防撤回难度最大，可能需要结合内存Hook，在表情包URL被加载到内存时进行捕获。

4.3 降低性能影响与实现后台化

定时截图OCR非常消耗CPU。优化方法：

1. 变化区域检测 ：先对聊天区域进行低分辨率截图或哈希计算，只有发现像素哈希值发生变化时，才触发高精度OCR，避免无谓运算。
2. 使用更轻量的OCR引擎 ：Tesseract功能强但重。可以尝试 PaddleOCR 或 Windows 10+自带的OCR API （ Windows.Media.Ocr ），后者性能通常更好。
3. 后台服务与托盘图标 ：将脚本打包为后台服务（Windows Service）或带有系统托盘图标的应用（如使用 pystray ），提供安静的启用/禁用开关，提升用户体验。

4.4 兼容性与版本适配

微信/QQ频繁更新，窗口类名、布局、甚至内存结构都可能变化。

• 配置化 ：将窗口类名、控件ID、区域偏移量等参数外置到配置文件（如JSON），方便用户根据自己版本调整。
• 自动探测 ：编写启发式算法，自动探测聊天区域。例如，寻找窗口内包含大量短文本行且滚动频繁的子区域。
• 社区维护 ：建立一个小型的版本-配置映射数据库，当检测到客户端版本更新时，提示用户或尝试自动下载对应的配置文件。

5. 常见问题、风险与伦理考量

在尝试实现或使用此类工具时，你必须清醒地认识到以下问题：

5.1 技术层面常见坑点

1. OCR识别乱码或失败 ：

   • 原因 ：聊天背景色、字体颜色、DPI缩放导致图像模糊。
   • 解决 ：截图后先进行图像预处理。将图像转换为灰度图，然后根据背景色进行二值化（阈值分割），突出文字。可以尝试多种阈值算法（如OTSU）。对于高分屏，确保截图时获取的是原始分辨率图像。

2. 无法定位到正确窗口或区域 ：

   • 原因 ：微信有多窗口（主窗口、聊天窗口、公众号窗口等），类名或标题不固定；DPI缩放导致坐标计算错误。
   • 解决 ：使用更精确的查找条件，如结合进程ID和窗口层级关系。对于DPI问题，使用 win32gui.GetDpiForWindow 获取窗口DPI，并进行缩放计算。所有坐标操作建议使用 win32gui.ScreenToClient 和 ClientToScreen 进行转换。

3. 程序占用CPU或内存过高 ：

   • 原因 ：循环间隔太短，OCR引擎未释放资源。
   • 解决 ：将循环间隔调整到合理值（如5-10秒）。确保在每次OCR完成后，及时清理临时图像文件。考虑使用多线程，将耗时的OCR操作放入独立线程，避免阻塞主循环。

5.2 安全与账号风险

这是最重要的一部分。

• 官方态度 ：微信/QQ用户协议明确禁止使用任何第三方软件修改客户端功能。任何形式的注入、修改内存、大规模自动化操作，都存在被检测的风险。
• 风险等级 ：
  • 高风险 ：直接修改 WeChatWin.dll 等核心文件、注入DLL、Hook关键函数。这类行为最容易被风控系统检测，可能导致短期封禁甚至永久封号。
  • 中低风险 ：本文所述的“外部监测”方案（截图OCR、文件监控）。由于不侵入进程，理论上风险较低，但并非零风险。频繁的截图行为如果被客户端检测到，也可能被标记为异常。
• 建议 ：
  1. 绝对不要 在主力账号、工作账号上测试或使用任何侵入性强的防撤回工具。
  2. 使用“小号”或测试账号进行所有实验。
  3. 明确工具用途，仅作为信息备份，切勿用于恶意目的。
  4. 了解并承担可能带来的后果。

5.3 伦理与隐私边界

技术是中立的，但使用技术的人需要自律。

• 尊重他人意图 ：消息撤回是发送者的权利。防撤回工具不应成为窥探他人隐私、收集不利证据的手段。它的合理使用场景应是： 在双方存在共识或出于必要工作留痕的情况下，作为接收方的辅助记录工具 。例如，在项目团队中，可以事先告知大家沟通记录会被完整保存用于回溯。
• 合法合规 ：确保工具的使用不违反任何法律法规，不用于窃取商业秘密、进行敲诈勒索等非法活动。
• 信息保管 ：保存下来的撤回消息属于敏感数据，应妥善保管，防止泄露。

我个人在实际探索中发现，构建一个稳定、通用且安全的“防撤回神器”极其困难，它更像是一个与官方客户端持续“博弈”的过程。对于绝大多数用户，如果真有强烈的防撤回需求，使用手机自带的通知历史记录（部分安卓系统支持）、或养成重要信息即时确认和备份的习惯，可能是更简单、更安全的方案。这个项目的技术探索过程，其价值远大于最终的工具本身——它让你深入理解了Windows桌面应用的工作原理、消息循环、UI自动化以及客户端安全的基本概念，这才是最大的收获。