简介一份基于Python的微信好友数据分析工具包面向Python数据分析初学者与社交网络分析爱好者帮助用户从微信好友信息中提取城市、性别、省份等分布特征并生成可视化图表。资源共5个文件包含1个Python主脚本、3个HTML可视化页面分别对应城市、性别、省份分析及1个pyecharts库安装包压缩包大小仅2.79MB轻量易用。目前已有71人学习/下载。读者可直接运行脚本处理自己的微信数据或打开HTML查看现成分析结果脚本结合Pandas与pyecharts演示了数据清洗、统计聚合与交互式图表生成的完整流程适合作为Python数据分析与可视化的入门实践样例。1. 微信好友分析.rar解压后先别急着跑得先搞懂它到底在读什么把「微信好友分析.rar」解压你大概率会得到一堆 Python 脚本、几张截图和一份说明文档。这类包我见过好几种核心思路其实只有一条读微信 PC 版留在本地的 SQLite 数据库把好友列表、聊天记录和标签转成结构化表格再做统计与画像。真正能一次跑通的包不多多数卡在解密这一步剩下不少是翻新脚本字段名对不上你的微信版本。这个方向值不值得做取决于你想拿它干什么。运营想整理客户关系社恐想看看自己到底和谁聊得最多数据分析新手想找一个真实、不造数、能反复练手的项目微信好友分析都合适——数据是你自己的就在你电脑里不需要爬接口不用碰服务器跑完还能顺带把 SQL 和 Pandas 练熟。这篇文章就把这条路径完整走一遍从文件定位到解密、解析、统计再写到避坑记录和增量工程化每一步都是可以直接照抄的程度。2. 解密微信好友数据的第一关定位 MicroMsg.db 并算出 SQLCipher 密钥2.1 微信 PC 版的关键数据文件在哪先找到 wxid 目录和 Msg 文件夹做微信好友分析的脚本第一步不是写代码而是先找到数据库文件。微信 PC 版的用户数据并不放在安装目录而是默认落在当前登录用户的数据目录下。不同版本的默认路径差异很大常见的老版本位置是「文档/WeChat Files/你的wxid/Msg」新版本客户端则挪到了「AppData/Roaming/Tencent/xwechat_files/」下按微信号分目录。找目录最稳的办法不是靠记忆而是打开微信的「设置 → 文件管理 → 打开文件夹」这个按钮点出来的位置就是数据库所在目录。进了这个目录后你会看到一堆.db 文件文件大小从几 MB 到几 GB 不等。老版本微信一般把数据拆成多个库分开存下表是常见的几个库和它们的用途文件名内容好友分析里做什么用MicroMsg.db联系人、会话列表、部分消息索引好友资料、昵称、备注ChatMsg.db聊天消息正文亲密度统计、聊天频率Contact.db新版联系人表地区、签名、性别等资料MediaMsg.db图片、视频、文件消息索引基本不用HardLink.db文件去重用的硬链接索引可忽略新版本微信里这些文件有时会被合并成一个大库或者改叫「msg」目录下的一堆分片库但「联系人表、消息表」这两个语义对应关系基本不变。定位到文件后先别急着用 Navicat 打开直接打开会报「file is not a database」因为微信的数据库是加密的。2.2 不太省心的 SQLCipher读懂微信数据库的加密结构再动手微信 PC 版用的是 SQLCipher 对 SQLite 数据库做透明加密。SQLCipher 的原理是在 SQLite 的文件格式外面套一层 AES 加密文件头的前 16 字节是随机 salt后面所有页都按加密后的格式写入。这意味着你拿普通 SQLite 工具是打不开的必须先提供正确密钥让 SQLCipher 重新解密每个页才能看到表结构。密钥的组成是微信的「原始 key」和数据库文件头里的 salt 一起参与哈希计算得到的。常见做法是从微信配置或登录态文件里提取原始 key对它做一次 MD5得到 32 字节的十六进制字符串;再把这个字符串与从数据库文件头读到的 16 字节 salt 拼起来作为 SQLCipher 的完整密钥。我在多个版本上踩过的坑是 MD5 结果的大小写小写能开大写就报「file is not a database」还有的老版本要显式关掉 HMAC 校验才能读表这个后面避坑章节会展开。这一段的重点不是把每一步讲成玄学而是一个操作顺序定位数据库文件 → 读文件头 salt → 准备原始 key → 拼密钥 → 用 SQLCipher 打开。原始 key 的提取方式跟微信版本强绑定老版本常用的是从运行中的微信进程内存里取新版本有的藏在 config 目录的配置数据里。自己分析自己账号数据时我一般会在微信完全退出的状态下优先尝试直接通过登录态缓冲文件构造密钥绕开内存操作少一点杀毒软件误报的麻烦。2.3 用 Python 算密钥并转存明文库一份可以直接跑的解密脚本落地步骤里我会先用 Python 脚本把加密库解密成普通 SQLite 库之后再拿 pandas 去读这样调试更直观也避免每条分析命令都要带密钥参数。依赖用 pysqlcipher3装不上时可以用 sqlcipher 命令行替代。下面这段是我常用的解密脚本骨架import hashlib from pathlib import Path from pysqlcipher3 import dbapi2 as sqlcipher db_path Path(./MicroMsg.db) # 微信联系人库 plain_out Path(./micro_plain.db) # 解密后的明文库 # 1. 从加密库文件头读 16 字节 salt with open(db_path, rb) as f: salt f.read(16) # 2. 原始 key 从登录态配置里提取这里以变量形式传入 raw_key bytes.fromhex(你的原始key十六进制字符串) # 3. 微信老版本密钥 md5(raw_key) 小写hex salt.hex() key_md5 hashlib.md5(raw_key).hexdigest() full_key key_md5 salt.hex() # 4. 打开加密库逐表复制到明文库 src sqlcipher.connect(str(db_path)) cur src.cursor() cur.execute(PRAGMA key \x%s\ % full_key) cur.execute(PRAGMA cipher_page_size 4096) cur.execute(PRAGMA cipher_use_hmac OFF) # 某些版本必须关否则下面查询报错 cur.execute(SELECT count(*) FROM sqlite_master) # 能查到表说明密钥正确 print(表数量:, cur.fetchone()[0]) dst sqlite3.connect(str(plain_out)) for t in [Friend, ChatMsg, Contact, ChatContact]: try: cur.execute(SELECT sql FROM sqlite_master WHERE name?, (t,)) row cur.fetchone() if row: dst.execute(row[0]) dst.execute(fINSERT INTO {t} SELECT * FROM {t}) except sqlcipher.DatabaseError: pass # 该表在当前版本不存在跳过 dst.commit()逻辑上分四步走先从文件头读 salt再算 MD5 拼接出 full_key然后用 PRAGMA key 把加密库「解锁」最后建一张数据库结构对照表逐表复制。这里有两个参数需要你根据自己的微信版本调整。第一个是cipher_page_sizeSQLCipher 的页大小不匹配时会出现「能打开库但读出乱码」的怪现象微信常见值是 4096我建议先把 4096 固定住不行再试 1024 或 8192。第二个是cipher_use_hmac老版本微信的加密参数不带 HMAC必须设成 OFF新版有的又必须恢复默认的 ON所以解密失败时这两个开关都测一遍能省下两小时排查时间。跑完这段脚本后你会得到一个完全明文的micro_plain.db之后的分析可以直接用标准库sqlite3读取也可以用 pandas 直接连。注意明文库不要再放回微信目录里单独扔到自己的工作目录避免微信启动时把它当成自己的数据文件读。3. 把好友资料变成 CSV解析 Contact 表的字段取舍与过滤条件3.1 Contact 表里哪些字段值得导昵称、备注、地区与签名的取舍拿到明文库之后先不要急着写统计逻辑第一件事是看看库里到底有哪些表、每张表有哪些字段。我一般是这样确认的SELECT name FROM sqlite_master WHERE typetable; SELECT * FROM Friend LIMIT 1;好友资料的核心在联系人表常见字段包括 UserName微信 ID、Alias微信号、NickName昵称、Remark备注、Province、City、Sex性别、Signature个性签名和 ContactLabel标签。但不是所有字段都值得进分析底表。我的取舍习惯是备注优先于昵称因为很多运营型好友的备注才代表真实身份地区字段尽量保留到市级省一级的粒度太粗做个热力图几乎没区分度签名是很好的文本挖掘原料但它经常为空不要让它影响主表的行数。另外还有个坑新版微信的昵称可能不再明文存在 Friend 表里而是被拆到一个单独的联系人资料表甚至带wc_前缀的字段里存的是脱敏数据。判断方法很简单导出一条记录看看 NickName 是正常中文还是一串编码。如果是一串编码就去查 Contact 表或 OpenIMContact 表优先从那里取明文昵称。3.2 写出好友分析 CSV过滤公众号、群聊和视频号的三条规则好友分析的底表最好导成 CSV后续用 pandas 处理最顺手。导出时最影响结果正确性的不是解析逻辑而是过滤条件。一个微信账号里混着好友、群聊、公众号、视频号和企业联系人如果不做区分统计出来的人数会虚高性别分布会被大量未知值稀释。我这边的三条硬规则是import csv import sqlite3 conn sqlite3.connect(micro_plain.db) out open(friends.csv, w, newline, encodingutf-8-sig) writer csv.writer(out) writer.writerow([wxid, nickname, remark, province, city, sex, signature]) cur conn.execute( SELECT UserName, NickName, Remark, Province, City, Sex, Signature FROM Friend WHERE UserName NOT LIKE %chatroom -- 排除群聊 AND UserName NOT LIKE %openim -- 排除公众号/视频号 AND UserName NOT LIKE %gh_% -- 排除服务号 AND UserName NOT LIKE %imel% -- 排除企业微信联系人 ) for wxid, nick, remark, prov, city, sex, sig in cur: # 昵称优先取备注备注为空才回退昵称 name remark or nick if not name: continue writer.writerow([wxid, name, remark, prov, city, sex, sig]) out.close()这段代码的过滤条件按优先级排列chatroom是群聊的统一后缀必须最先排除openim是公众号和视频号常见后缀gh_开头的是公众号的服务号imel我遇到过是企业微信联系人。四类过滤条件全部命中后剩余的行才是真正意义上的个人好友。过滤之后还做了一个「备注优先」的处理name remark or nick这一行很关键因为做客户运营的人往往在备注里写的是「张总-上海-采购」昵称反而是花名用备注做后续聚合才有业务含义。导出用utf-8-sig编码而不是utf-8是因为 Excel 直接打开 CSV 时带 BOM 的 UTF-8 才不会显示乱码这是 Windows 场景下的一个玄学点但很实用。3.3 为什么好友总数总是少几个去重和僵尸号的边界处理导出的 CSV 行数如果比自己通讯录里数出来的少几个先别慌不一定是脚本错了。微信的数据库里本来就存在「已删除好友但未清理的会话记录」「单向删除但本地还留着聊天」这样的情况。去重逻辑上我一般以 UserName 作为唯一键做一次 group byNickName 和 Remark 取非空值优先import pandas as pd df pd.read_csv(friends.csv, dtype{wxid: str}) df df.drop_duplicates(subsetwxid, keepfirst) # 定义一个“有效好友”的判定规则 valid df[df[wxid].str.contains(, naFalse) False | df[wxid].str.startswith(wxid_)] print(原始行数:, len(df), 去重后:, len(valid))这里真正要理解的是 startswith(wxid_) 这条规则的意义。老版本微信的好友 wxid 统一以wxid_开头新版有部分账号是自定义微信号不会带wxid_前缀。如果直接用NOT LIKE wxid_%去筛会把自定义微信号的好友全删掉所以正确逻辑是「排除明显不是个人号的类型」而不是「只保留 wxid_ 开头」。僵尸号的边界问题我通常这样处理如果一段好友关系已经超过 180 天没有任何聊天记录就把他们单独打标为「沉默好友」不进亲密度排名正文只进总量统计。这样既不会让真实好友数显得虚高也不至于把这部分人彻底丢掉——也许哪天你还要给他们发一次活动通知呢。4. 用聊天记录给好友关系打分亲密度统计与分布画像4.1 ChatMsg 表怎么统计单聊IsSender 分向、CreateTime 限时好友资料只能给出静态画像真正能反映「你和谁关系近」的数据在聊天记录里。ChatMsg 表是消息正文表字段一般包括 StrTalker对方的 wxid、IsSender是否自己发送、Type消息类型、CreateTime消息时间戳。统计单聊亲密度时我最在意的三个点是对方维度要排除群聊IsSender 要分方向统计时间范围要可配置。import sqlite3 from collections import Counter conn sqlite3.connect(micro_plain.db) # 只统计单聊按对方收发方向分组 cur conn.execute( SELECT StrTalker, IsSender, COUNT(*) AS cnt FROM ChatMsg WHERE StrTalker NOT LIKE %chatroom AND StrTalker NOT LIKE %openim AND CreateTime strftime(%s, 2024-01-01) -- 只算近一年的消息 GROUP BY StrTalker, IsSender ) send_cnt, recv_cnt Counter(), Counter() for talker, is_sender, cnt in cur: if is_sender 1: send_cnt[talker] cnt else: recv_cnt[talker] cnt为什么单聊统计必须用StrTalker而不是StrTalker IsSender合并因为一条消息记录的 StrTalker 永远是对方的 wxid无论消息是你发的还是对方发的。群聊场景下 StrTalker 是群 id所以先用 NOT LIKE 过滤掉chatroom。时间范围用strftime(%s, 2024-01-01)把日期转成 Unix 秒级时间戳再比较是兼容性最好的写法比直接传字符串时间更稳因为不同版本的微信 CreateTime 字段有的是秒级有的是毫秒级后面避坑章节会专门说。4.2 亲密度排名的 SQL 与 Python 聚合三行代码拿到 Top 10有了 send_cnt 和 recv_cnt 两个 Counter 之后计算亲密度就有很多种口径。最简单也最不容易被质疑的口径是「双向消息总量」。这个指标的缺点是会被群发消息干扰比如你做运营给每个客户都群发过差不多量的话术那 Top 10 全是群发对象看不出实际关系。所以我习惯再算一个「主动率」辅助判断对方发起的消息占比越高通常代表对方更主动维系关系。import pandas as pd # 把两个 Counter 拼成 DataFrame talkers set(send_cnt) | set(recv_cnt) rank pd.DataFrame({ wxid: list(talkers), 我发出: [send_cnt.get(t, 0) for t in talkers], 对方发出: [recv_cnt.get(t, 0) for t in talkers], }) rank[总量] rank[我发出] rank[对方发出] rank[对方主动率] rank[对方发出] / rank[总量] # 关联好友资料表把 wxid 换成备注名 friends pd.read_csv(friends.csv, dtype{wxid: str}) rank rank.merge(friends[[wxid, nickname]], onwxid, howleft) print(rank.sort_values(总量, ascendingFalse).head(10).to_string(indexFalse))这段代码最后 merge 了一次好友资料表把 wxid 映射成备注名。为什么要关联而不是直接展示 wxid因为 wxid 对读者没有任何语义只有替换成人名后排名才有解读价值。merge 用 howleft 保证聊天记录里有、但好友表里已经删掉的人也能保留下来避免统计口径不一致。参数上对方主动率的阈值我一般设为 0.6超过 0.6 说明对方主动找你更多低于 0.4 说明你单向维系这段关系这样的好友如果超过 20 个就得想想自己是不是太累了。4.3 好友分布四象限按地区、性别、标签和消息频率一起看单聊排名能看到个体但做好友分析不能只看个体还要看群体结构。我习惯把整个好友列表按四个维度做成四象限地区分布、性别比例、标签占比、消息活跃度。一份常见的好友数据在四个维度上的分布如下表维度常见观测结果值得注意的信号地区同城好友占比高异地比例畸高可能说明线上社群粉丝多性别性别分布天然不平衡未知性别占比超过 20% 说明资料缺失严重标签没有标签的比例高可运营空间大但关系深度可能不足活跃度近一月有聊天的占比低于 30% 说明大量关系已经沉默代码层面我直接基于 friends.csv 做透视import pandas as pd df pd.read_csv(friends.csv, dtype{wxid: str}) # 地区分布省份为空的行单独归为“未知” df[省份] df[province].fillna(未知) city_stat df.groupby(省份).size().sort_values(ascendingFalse).head(15) print(city_stat) # 性别分布0未知 1男 2女 print(df[sex].value_counts()) # 活跃度与亲密度排名表做交集 active_wxids set(rank[wxid]) # 近一年有聊天的人 df[近一年活跃] df[wxid].isin(active_wxids) active_ratio df.groupby(省份)[近一年活跃].mean() print(active_ratio.sort_values(ascendingFalse).head(10))性别映射上sex 字段的取值我自己见过 0、1、2 三档0 代表未设置。有个值得玩的细节df.groupby(省份)[近一年活跃].mean()算出来的是各省好友的活跃率不是数量。做客户运营时一个省份如果好友量大但活跃率很低说明那批线索质量差后续渠道投放要调整。做个人社交分析时这个指标能帮你发现「虽然加了很多老乡但真正聊得来的一个都没有」——这类反直觉结论才是把分析落地成行动的价值所在。5. 微信好友分析避坑记录解密失败、好友数对不上和版本升级5.1 现象解密时提示 file is not a database这是跑微信好友分析脚本最常见的翻车点几乎每个第一次接触 SQLCipher 的人都会遇到。文件看起来是 .db 后缀双击或用 Navicat 打开时工具直接报「file is not a database」或「encrypted database」。原因和解决路径分两层看如果是加密库但没解密报这个错很正常如果是自己刚跑完解密脚本、复制出来的明文库也报这个错那就要检查复制文件时微信是不是还在后台运行。微信运行时会独占数据库文件并利用 WAL 模式把新数据写在-wal文件里。如果你直接复制整个目录复制到的可能是「没刷盘」的旧数据甚至复制时文件被占用导致字节不完整。解决方法是复制数据库前先完全退出微信确认进程列表里没有 WeChat.exe 或 Weixin.exe再执行一次复制如果只复制了MicroMsg.db而漏掉了同目录下的MicroMsg.db-wal文件解密出来的库会缺失最近一段时间的会话对账时聊天条数对不上。5.2 现象密钥算对了却读不到任何表之前讲过 SQLCipher 的 HMAC 开关会直接影响读表。最常见的表现是PRAGMA key 执行没有报错但执行SELECT count(*) FROM sqlite_master返回空或者直接报「no such table: Friend」。原因有两个大小写问题和 HMAC 开关问题。微信内部拼接密钥时用的是小写十六进制而你自己写的hashlib.md5(...).hexdigest()默认也是小写看起来没问题但如果你为了对齐某个网上脚本改成.upper()立刻打不开。HMAC 方面SQLCipher 2.x 没有 HMAC3.x 默认开启微信老版本为了兼容用的是关闭模式。解决路径我给一个固定的排查顺序先确认 salt 是直接从文件头读的不要用网上贴的固定值再确认 MD5 输出全小写最后把cipher_use_hmac在 ON 和 OFF 之间各试一次。三条都排除后仍然失败就去检查cipher_page_size适配顺序是 4096 → 8192 → 1024。这套顺序在 SQLCipher 兼容问题上基本能覆盖九成情况剩下那成是微信小版本自己改参数只能等社区更新适配。5.3 现象昵称和地区大面积为空解密成功、CSV 也导出来了但一看数据昵称列一大半是空值地区列几乎没有有效内容。这不是过滤条件写错而是新旧版微信的存储结构差异。新版微信把联系人资料拆到了独立表里Friend 表只剩 wxid、备注等基础字段地区、签名、性别等明细挪到了 OpenIMContact 或 Contact 表甚至昵称会以「加密昵称」的形式存在别处。解决思路是先从 sqlite_master 把所有表名列出来重点找名字含contact的表逐一看字段再把 Friend 表和 Contact 表按 wxid 做 LEFT JOIN用 COALESCE 把 NickName 的取值设为「Contact 表的明文昵称优先Friend 表的备注兜底」。我用过的脚本里还出现过一种情况地区字段拆成两个字段存一个存国家/省份一个存城市拼接时机要选对不然会出来「中国中国」这种重复文本。5.4 现象好友数量比通讯录里数的少了将近一成通讯录里手动数出 800 个好友脚本导出来只有 730 个。这类偏差几乎都是过滤条件过严。很多人会把「排除非好友」理解成「排除所有不认识的 id」然后误杀了自定义微信号好友。自定义微信号不一定带wxid_前缀也不带特殊后缀它们在数据库里就是一行普通字符串。正确做法是先看好友表里 UserName 的取值形态再决定排除规则而不是拿着别人的脚本直接跑。另一个被低估的原因是「仅聊天」权限的好友。微信把「仅聊天」好友和正常好友在部分版本里用 Type 字段区分有的脚本复制时漏了这部分导致总量偏少。对账时我一般用「最近聊天人数量 好友表存在但近 180 天无聊天人数 僵尸号保护名单人数」三份数据集交叉验证能覆盖情况更全面。如果总量还是对不上就看一眼 Friend 表里有没有一行 UserName 是你的自己 wxid有的版本会把自己也写进好友表统计时应排除。5.5 现象微信小版本升级后脚本集体失灵这是做微信好友分析最难受的坑它不是 bug是微信升级改了存储格式或者加密参数。常见的表现是昨天还能跑通的解密脚本今天报错或者解密成功但原来名为 Friend 的表不见了改成了 Contact 表。我的应对是把它当成工程问题来管理。第一每次跑分析前先执行一句「环境自检」尝试解密并读取表数量和上次结果比对数量对不上就停止分析并提示检查版本。第二所有解密参数单独抽成一个配置文件不散落在脚本里升级后只改参数不改逻辑。第三升级前把明文数据库做一次完整备份这是你的后悔药——新版脚本跑崩了至少还能用旧明文库把历史分析先出完。微信 PC 版更新频率不算高但这套保护机制能让你在升级后的第一个小时里不用手忙脚乱找旧版本安装包。6. 把分析脚本做成能持续用的工程增量导出与固定节奏6.1 增量不是重跑全量用 CreateTime 断点恢复好友分析跑一次容易难的是每周都能稳定跑一次。全量解密聊天记录库在数据量大时非常慢而且每次全量跑都要处理整个 ChatMsg 表无效计算太多。我后来把流程改成了增量模式每次跑完记录当前最大 CreateTime下次只处理新增时间窗口的数据最后合并回上一份结果。import json import sqlite3 from pathlib import Path state_file Path(./state.json) state json.loads(state_file.read_text()) if state_file.exists() else {last_ts: 0} conn sqlite3.connect(micro_plain.db) cur conn.execute( SELECT StrTalker, IsSender, Type, CreateTime FROM ChatMsg WHERE CreateTime ? ORDER BY CreateTime ASC , (state[last_ts],)) new_rows cur.fetchall() if new_rows: max_ts new_rows[-1][3] state[last_ts] max_ts state_file.write_text(json.dumps(state)) # 把 new_rows 合并进已有的统计结果表增量逻辑上有两个细节值得注意第一ORDER BY CreateTime ASC是为了让new_rows[-1][3]一定是本次最大的时间戳这样断点才能持续向前推进否则下次可能漏消息第二断点用秒级时间戳存储如果你发现微信某个版本把 CreateTime 从秒级改成毫秒级一定要在读取时统一除以 1000否则「下次跑增量会漏掉 1970 年的假数据」这个低级错误就会找上门。数据合并时我习惯不直接删除旧结果而是以「wxid 对方 月份」为唯一键做 upsert这样哪怕某周增量跑了重复数据也不会污染最终统计。配合 Windows 任务计划程序里每周日凌晨跑一次的定时触发这套流程可以做到无人值守。6.2 数据快照与对拍升版前的后悔药增量方案里最重要的不是增量本身而是对拍机制。我吃过一次亏微信做过一次小版本升级后消息表的时间字段语义被变更我的增量脚本把半年的历史消息全当成新数据重复统计了一遍亲密度排名彻底失真。后来我固定下一个习惯——每次升版后第一次跑全量第二次跑增量用两次结果做 diff差异行数占比超过 5% 就停下来检查字段语义。对拍脚本的核心也比较简单把两次导出的 CSV 读进来按 wxid 和月份 key 做 merge找出只在全量里出现的行。这些行如果集中在旧时间范围说明增量断点失效如果是新时间范围反而说明增量工作正常。另外每次升级前给明文库保留一个带日期的快照文件例如micro_plain_20250101.db既不占太多磁盘空间又能在新版本完全不兼容时回滚到旧版本完成当周分析。这套数据快照加对拍的组合是我踩过多次坑之后才固定下来的工作方式希望也能帮你少走一段弯路。好友分析这个方向本身不难难点全在「你的版本和脚本假设的版本是否一致」。只要你把解密参数、表名、字段语义这三个地方做成可配置不管手上拿到的是哪种「微信好友分析.rar」都能改一改跑起来。希望帮到你。本文还有配套的精品资源点击获取