简介基于本地Web服务的微信好友检测工具面向需要管理微信好友、排查单向好友或拉黑情况的普通用户与具备轻度技术背景的爱好者通过浏览器获得直观的可视化操作界面无需了解命令行即可上手。工具核心逻辑在本地运行适合注重隐私且希望快速维护好友关系的场景。资源包共68个文件压缩包约27.16MB涵盖可直接运行的exe主程序、Python源码与pyd编译模块、前端js/css/html页面、conf/yml配置文件及多份docx说明文档兼顾一键使用与二次开发需求。目前已有472人学习/下载。包内还整理了Redis、微信协议侧的配置说明与关键使用要点可帮助用户避开端口占用等常见问题理解基于本地Web服务的工作机制附带的文本也对易错点做出提示整体实用性强适合需要快速判断好友状态的个人用户参考。1. 微信好友检测工具先搞清楚它到底在检测什么微信好友数量常年顶着上限、通讯录里躺着一年没说过话的熟人这些情况的真实占比远比我们印象中高。微信好友检测工具解决的正是这个需求找出已经把你删除、拉黑的单向好友从而清理通讯录、腾出好友名额。这类工具的检测逻辑并不依赖官方后台数据而是通过客户端返回的交互文案来判断关系状态——原理不复杂但边界条件极多自己写容易漏判拿来主义又怕踩风控。这篇文章会拆一套完整可复现的工具包告诉你检测路径怎么选、参数怎么调、哪些情况会翻车。2. 三种检测路径与选型为什么最后选了建群法2.1 转账法信息最准确但成本高转账法指在聊天窗口给好友发起一笔小额转账微信会在确认支付前返回对应的好友状态。正常好友会进入输入密码页面被对方删除时返回“对方开启了朋友验证你还不是他朋友”被拉黑时返回“消息已发出但被对方拒收了”账号注销时返回“对方账号已注销”。判定结果非常精确几乎没有歧义。但这套方案有个硬伤只能逐人操作一个通信录里有上千人的话全部走转账法意味着上千次打开聊天窗口、上调转账金额、再取消的操作。就算脚本能模拟点击这个频率也极大概率触发系统风控。我见过有人用自动化框架批量跑转账法跑了不到两百人就被限制了收款功能得不偿失。还有一个坑容易被忽略转账法会对好友产生“打扰”。哪怕你取消了转账对方端也有可能出现一条“对方正在向你转账”的服务通知。试想一下一个好久没联系的人突然弹出转账通知又没实际收到钱这是很尴尬的事。所以转帳法我只建议用来复核可疑账号不适合全量扫描。2.2 朋友圈互动观察法零打扰但误判率高朋友圈互动观察法不需要给好友发任何消息只要进入对方朋友圈主页观察可见状态和互动痕迹即可判断。正常情况下你能看到对方朋友圈内容和互动记录被删除的话进入朋友圈会显示“对方未开启朋友圈”或只能看到一条灰线被拉黑则直接提示“对方开启了朋友验证”。这个方法的最大优点是零打扰、零风控风险适合批量检测——写一个脚本模拟进入每人的朋友圈主页读取返回状态即可。但它的准确率存在问题第一对方关闭朋友圈、设置“仅展示最近三天”且三天内未发内容时你看到的界面和被删除时几乎一样都是灰线或空白容易把正常好友误判成单向好友。第二被删除后若对方重新把你加回来历史朋友圈互动记录依然可能残缺不全脚本很难通过互动数据区分“短期未发动态”还是“已被删除”。第三微信客户端的界面文案在不同版本上并不完全一致灰线判定逻辑在不同手机型号上出现过反例。所以朋友圈观察法适合做预筛筛出“疑似单向”的候选名单再用其他方法复核不适合直接作为最终判定依据。2.3 建群法批量检测的可落地方案建群法是目前批量检测最常用的路径。原理是创建微信群并拉指定好友入群正常好友会被拉进群已经被删除的好友系统会提示“无法邀请该好友请先向对方发送好友验证”被拉黑的好友则表现为邀请后对方一直不进入群聊且群内会出现带红色感叹号的灰色气泡。建群法真正的价值在于单次操作覆盖多个目标。你可以在一次建群操作中同时检测最多几十个好友检测效率比转账法高出一个数量级。同时它不产生“转账通知”这种强打扰信号被拉进群又马上退群很多人根本来不及看到。本工具包选型的核心逻辑是转账法做复核、朋友圈法做预筛、建群法做批量主检测。工具包内的脚本负责名单生成、分批、结果记录和用户状态合并而建群这个动作由你手动在微信客户端里完成脚本不模拟点击、不触碰客户端自动化从源头上规避了风控风险。# detection_paths.py —— 选择检测路径的核心逻辑 def decide_path(friend_status: str, batch_scale: int) - str: if batch_scale 3: # 少量关键好友用转账法复核 return transfer if batch_scale 40: # 超过单批上限的走朋友圈预筛 return moments # 其余场景全部走建群法 return group_invite这段代码表达的是实际检测时的路径选择策略。入参batch_scale指本轮要检测的好友数量friend_status是上轮预筛结果。逻辑上少量目标用转账法拿最精确的结果大批量目标先用朋友圈法降噪中间体量的直接建群。参数注释里已经点明了关键阈值转账复核建议控制在 3 人以内建群单批不要超过 40 人超出部分必须拆批否则容易被风控盯上。3. 工具包结构与环境准备从下载到跑通第一张名单3.1 工具包目录与文件清单解压工具包之后的目录结构设计遵循“输入、配置、脚本、输出”四段式方便维护和换机迁移。完整文件如下文件作用requirements.txtPython 依赖清单只用到标准库和 pyyamlconfig.yaml核心参数配置包括批次大小、间隔范围、输出目录clean_list.py清洗并分批好友名单生成待检测 CSVmerge_result.py合并手动判定结果输出“可删除名单”和“已拉黑名单”daily_report.py汇总检测报告统计有效好友、单向好友、拉黑好友占比samples/friends_sample.csv示例名单包含微信昵称和微信号两列docs/操作手册.pdf建群操作与文案判定的图文对照表这个结构的用意在于脚本之间通过标准 CSV 传递数据清洗脚本产生的分组文件直接作为检测工作表检测完成后把手工标注的结果喂给合并脚本最终产物是一份可直接用于删好友操作的清单。每一步的输出都是下一步的输入中途哪怕中断也不会丢进度。3.2 Python 环境准备与依赖安装建议用 Python 3.10 以上版本避免低版本在标准库行为上的差异。依赖只有 pyyaml 一个第三方库其他全部使用标准库这样在离线环境也能部署。# 创建虚拟环境并激活Windows 使用 venv\Scripts\activate python -m venv .venv source .venv/bin/activate # 安装依赖 pip install -r requirements.txtrequirements.txt里内容极少核心就一行pyyaml6.0.1。之所以固定主版本号是因为 yaml 库在 5.x 到 6.x 之间对safe_load的行为做了调整不锁版本的话不同机器上读配置可能遇到兼容性差异。这里没有用 pandas 之类的重量级库因为名单处理只是读取和去重标准库 csv 模块完全够用减少依赖就是减少环境搭建时的翻车概率。3.3 准备名单并跑通清洗脚本在samples/friends_sample.csv中准备名单格式是两列昵称列用于人眼识别微信号列是脚本处理的依据。# 运行清洗脚本生成分批后的检测名单 python clean_list.py --input samples/friends_sample.csv --batch-size 40 --output ./batches脚本会输出类似batch_001.csv、batch_002.csv的分组文件。每个文件内包含最多 40 个好友并自动完成三件事去掉包含特殊字符的异常行、用微信号去重保留昵称更完整的那条、随机打乱顺序。随机打乱的目的是避免每次检测都从同一个好友开始——如果连续多次检测都固定从通讯录头部开始系统侧更容易捕捉到规律性操作随机化本质上是把操作模式变得接近真人。# clean_list.py 内部核心逻辑 import csv, random, sys, os from collections import OrderedDict def load_friends(csv_path: str): seen OrderedDict() with open(csv_path, r, encodingutf-8-sig) as f: for row in csv.DictReader(f): wx_id row[微信号].strip() # 微信号为空或格式异常的直接跳过 if not wx_id or len(wx_id) 8 or len(wx_id) 25: continue # 去重同一个微信号保留第一条 if wx_id not in seen: seen[wx_id] {昵称: row[昵称].strip(), 微信号: wx_id} return list(seen.values()) def split_batches(friends, batch_size40): random.shuffle(friends) for i in range(0, len(friends), batch_size): yield friends[i:i batch_size]load_friends里的utf-8-sig编码专门兼容 Excel 导出的带 BOM 头的 CSV否则第一列列名会出现\ufeff昵称导致 DictReader 找不到对应字段。微信号长度限制在 8 到 25 位之间过滤掉明显是错误粘贴的内容。split_batches先洗牌再切片每批严格不超过 40 人这是综合检测效率和风控安全之间的经验值。第一张待检测名单跑通之后打开batch_001.csv就能看到本批要建群的 40 个好友。接下来的检测动作都在微信客户端里手动完成脚本只负责名单准备和结果归集。4. 核心参数与判定逻辑如何让脚本替你判断“已删除”还是“已拉黑”4.1 客户端返回文案与状态码映射这一节是整个工具包最核心的部分。建群操作中针对不同好友状态微信客户端会给出不同的提示文案。脚本本身不解析文案但合并脚本依赖你按状态码手动标注因此必须先建立一套固定的映射表。以下是微信主流版本中常见的文案对照工具包操作手册里同样附了这一份状态码客户端返回文案特征关系判定处理建议normal拉人入群成功无异常提示正常好友保留deleted提示“请先向对方发送好友验证”对方已删除你可删blocked群聊中出现灰色气泡红色感叹号对方已拉黑你可删需确认banned提示“对方账号状态异常”账号封禁或注销暂留观察建群时还有一个最容易被误解的文案系统提示“无法邀请XXX请先向对方发送好友验证”但同时又显示邀请成功。这种情况通常出现在对方隐私设置关闭了“允许通过群聊添加”时并不一定代表对方删除了你需要以最终群内是否出现红色感叹号为准。也就是说文案只能作为第一信号最终判定要看灰色气泡。工具包的判定规则里强制要求两步确认先记录文案再检查群成员列表两次结果均指向同一状态才算定论。4.2 参数配置批次、间隔与安全阀config.yaml中的参数决定整轮检测的安全边界和效率平衡。默认配置如下# config.yaml 核心参数说明 detect: batch_size: 40 # 每批最多拉 40 人超出会触发风控 min_interval: 60 # 两批之间的最短间隔秒 max_interval: 120 # 两批之间的最长间隔秒 daily_limit: 3 # 单日最多检测 3 批超过强制结束 confirm_method: group_bubble # 判定依据群内气泡而非邀请文案 output: result_dir: ./results delete_list: delete_list.csv block_list: block_list.csvmin_interval和max_interval不是固定值而是生成一个随机区间。假如固定每批间隔 90 秒操作规律性太强容易被识别为程序化操作如果间隔随机分布在 60 到 120 秒之间操作曲线就更接近真人手动处理。daily_limit是硬性安全阀单日超过 3 批后无论还剩多少名单脚本都会拒绝继续生成新批次。这个参数结合“每次检测间隔至少两周”的使用习惯能把账号风险压到可控范围。4.3 结果合并脚本从手动标注到最终名单检测完成后打开每个批次的 CSV 文件在最后一列填入状态码保存后将所有批次文件交给合并脚本处理。# 合并所有批次结果生成最终清单 python merge_result.py --input ./batches --output ./results# merge_result.py 内核对状态码的分类逻辑 import csv, glob, os, sys from collections import Counter def merge_batches(batch_dir: str, result_dir: str): delete_rows, block_rows, normal_rows [], [], [] status_counter Counter() for path in glob.glob(os.path.join(batch_dir, batch_*.csv)): with open(path, r, encodingutf-8-sig) as f: for row in csv.DictReader(f): status row.get(检测结果, unknown).strip().lower() status_counter[status] 1 if status deleted: delete_rows.append(row) elif status blocked: block_rows.append(row) else: normal_rows.append(row) os.makedirs(result_dir, exist_okTrue) for filename, rows in [ (delete_list.csv, delete_rows), (block_list.csv, block_rows), ]: with open(os.path.join(result_dir, filename), w, encodingutf-8-sig, newline) as f: writer csv.DictWriter(f, fieldnames[昵称, 微信号, 检测结果]) writer.writeheader() writer.writerows(rows) print(f正常好友: {status_counter[normal]} 人) print(f单向删除: {status_counter[deleted]} 人) print(f拉黑好友: {status_counter[blocked]} 人)这段代码会扫描batches目录下所有以batch_开头的 CSV 文件按照检测结果列写入最终清单。delete_list.csv是清理通讯录的直接依据block_list.csv单独列出防止你误删后想恢复却找不到人。这里故意不做自动删除操作——删好友是一个不可逆动作脚本只生成清单最终决策权留给你。5. 避坑与常见问题风控、误报和三十天后的翻车现场5.1 建群频繁导致功能被限制现象按工具包流程跑了三批之后再建群时微信提示“操作过于频繁请稍后再试”严重时甚至出现“该账号已被限制使用部分功能”。原因建群本身不是高频用户行为短时间内连续拉人建群会被系统判定为异常批量操作。很多人只看群数量而忽略退群动作——创建一个群再马上解散这组行为模式本身就是风控模型的重点特征。解决把检测频率压到每周一次每次不超过三批。建完群后不要立刻解散群聊让群至少保留 15 到 30 分钟再自行处理模拟正常使用群聊的行为。我在工具包里默认把daily_limit设为 3就是基于这个经验值。5.2 文案提示“需要验证”但对方其实没删你现象拉人建群时提示“请先向对方发送好友验证”但等群建好后群里所有成员都显示正常没有红色感叹号。原因这个坑最初困扰了很久。后续用转账法复核后发现这部分好友的隐私设置中关闭了“允许通过群聊添加我”系统在邀请时仍然会弹出验证提示但实际邀请已经成功。也就是说邀请提示文案和入群结果之间并不完全同步。解决判定规则里强制要求“文案群内气泡”双重确认。文案只是触发警报的第一信号最终以群成员列表里的气泡状态为准。如果文案异常但群里一切正常标记为normal并备注“隐私限制”不要划入删除名单。5.3 拉黑与删除混淆导致误删现象有人把检测结果里标成deleted的好友直接删了之后发现这位其实只是拉黑了自己并没有删除好友关系。原因删除和拉黑在客户端表现上确实存在混淆区。被拉黑后拉人建群文案有时也显示“请先发送验证”与删除状态的第一信号几乎一致。但两者在群聊内的表现不同删除状态下邀请会失败群内根本没有这个人拉黑状态下群内会出现灰色气泡成员。解决拉黑和删除在最终名单里分开输出。处理建议也不同——删除状态的好友可以直接清理拉黑状态的好友建议先留一个月因为部分情况下对方只是临时屏蔽后续可能解除。直接删掉拉黑你的人事后如果再想联系对方那边会显示“你还不是他朋友”连解释的机会都没有。5.4 微信版本升级后文案变化导致漏判现象一次检测中有多个好友状态无法匹配映射表脚本统计出的unknown状态暴增合并清单显示异常。原因微信客户端升级后部分提示文案发生了细微变化。例如旧版本返回“对方开启了朋友验证”新版本可能显示“请先向对方发送朋友验证申请”两个文案指向同一状态但写死的字符串匹配逻辑无法识别。解决不要对文案做全字匹配而是做关键词匹配。工具包的merge_result.py改用“包含”而非“等于”的匹配方式匹配关键子串如“朋友验证”“拒收”“账号状态异常”。同时建议每次检测前先在一个老群里做三次试探性操作确认当前版本的文案特征没有变化。5.5 恢复备份发现误删好友没有后悔药现象清理完名单后一个月有事情需要联系一位被删好友却发现找不到人而且记忆中对方的微信号也没有留存。原因这是流程设计问题不是检测逻辑问题。删除动作执行得太干脆没有保留检测时的完整快照。工具包输出的delete_list.csv只有昵称和微信号但如果昵称是随手起的微信号又记不清事后根本无从找回。解决调整操作顺序——删除前先对delete_list.csv里的好友分别打开一次聊天窗口截屏保存完整聊天记录和资料页信息。工具包新增了backup_chat.py辅助脚本可以批量生成“进入聊天窗口→等待三秒→截屏”的操作提醒清单三秒时间足够切到聊天记录页再截屏。从那以后我每次跑完检测都强制走一遍备份流程。这个额外步骤花不了几分钟但能避免“手滑删错人”之后彻底失联的窘境。希望帮到你。本文还有配套的精品资源点击获取