用Python分析微信好友数据：从采集到可视化的完整实践指南

微信好友从一百涨到一千的时候，我突然发现自己对“好友”这两个字的理解其实变得很模糊。朋友圈刷不完，通讯录翻不到底，很多人躺在里面几年不互动，我甚至想不起是在什么场合加的。也就是在那一刻，我决定把微信好友列表当成一个正经的分析对象来处理——不是挨个备注“认识/不认识”，而是用数据分析的方式，去回答一些平时靠感觉根本无法回答的问题。

这个项目没有特别大的商业场景，就是一次标准的个人数据管理实践：把微信生态里散落的、非结构化的社交关系，经过采集、清洗、加工、分析，最终变成一组图表和一份可复用的分析报告。它能完整锻炼 Python 数据分析的常规流程，也能让我们重新看清自己的社交网络。如果你平时用 Python + pandas + pyecharts 做数据处理，或者正在准备数据分析师的面试，这个项目都很适合拿来练手。

整个项目的技术链路其实不浅：数据采集涉及多端配合，清洗阶段要处理各种空值和脏文本，分析阶段要选择合适的可视化图形，最后还得考虑隐私保护和结果验证。下面按一条实际可复现的主线，把每一步拆开讲清楚。

1. 项目动机与目标：为什么要把好友列表当数据集来做

1.1 我的处境与一个具体的问题

先说背景。我的微信好友数在去年年底突破了 1200，职业原因导致好友来源非常杂：有工作伙伴、有同学、有小区邻居、有各种线下活动加的、还有误加的微商。我意识到自己根本回答不了几个简单问题：

• 我的好友里到底是同城的人多，还是外地的人多？
• 过去一年里，真正跟我保持高频互动的有几个人？
• 我加的“陌生人”比例是不是太高了？
• 我的标签体系到底健不健康？

这些问题的共同点是：凭印象回答会非常主观，而且大概率是错的。我知道的只有“好像挺多”“不太清楚”“可能吧”。数据分析恰好能解决这类问题——先把信息结构化，再用统计学方法压缩成可读的指标和图表。

1.2 项目最终产出清单

做这个项目前，我先列了一份交付物清单，防止自己做着做着就跑偏。最终产出包括：

• 一份清洗后的好友信息表，包含昵称、性别、地区、标签、备注名、添加年份等字段；
• 一份互动行为统计表，包含聊天条数、最近互动时间、活跃度等级等派生字段；
• 一份 HTML 交互式分析报告，用 pyecharts 生成，包含地域分布、性别比例、标签结构、活跃度分层等图表；
• 一段可直接复跑的 Python 脚本，从原始数据到报告一键生成；
• 一份踩坑记录，记录过程中遇到的中文编码、Linux 界面渲染、Excel 导出等问题。

这份清单的好处是，它让我在动手之前就想清楚了“做到什么程度算完成”，后续每一步都变得有据可依。

1.3 整体技术路线

整条技术路线我用一句话概括：原始登记表 → 结构化清洗 → 特征构建 → 图表呈现 → 结论复盘。

具体步骤是：

1. 通过微信客户端的通讯录视图，把好友的公开信息登记到本地；
2. 用 pandas 读取登记表，检查数据质量，处理缺失值和重复项；
3. 基于本地的聊天记录备份文件，提取最近互动时间和聊天频次；
4. 构建“活跃度”“社交密度”“沉默期”等派生特征；
5. 用 pyecharts 制作可交互图表，输出分析报告；
6. 根据图表数据调整结论，顺便验证几个最初的假设。

这个路线不依赖任何非公开接口，运行环境只需要 Python 3.9+ 和几十 MB 的第三方库，成本很低，复现性也很强。

2. 数据采集的边界、方案与字段设计

2.1 微信生态里能合法触达的数据字段

很多人的第一反应是：好友数据不就是通过接口拉一下列表吗？但实际在微信生态里，个人能合法、稳定触达的字段并没有那么多。

结合我这个项目的实际场景，能拿到且值得分析的字段分为三类：

要注意，所有字段都必须限定在“你自己账号所能看到的数据范围”内，不能通过任何方式去获取他人隐私数据。采集前先想清楚这个边界，后面才能做得安稳。

2.2 三层采集方案

我的采集方案是“三层采集法”，不依赖任何非官方接口，也不触碰账号安全红线。

第一层是整理层。打开微信通讯录，按照标签和字母顺序，把好友的备注名、性别、地区、签名等肉眼可见的信息登记到本地 Excel 或 CSV 中。这一步看着繁琐，但实际上只要做好批处理，花一两个小时就能完成。如果你好友特别多，还可以先按标签导出，减少重复劳动。

第二层是补全层。微信客户端提供了聊天记录备份功能，把聊天记录备份到本地后，会生成一个数据目录。我的做法是结合自己的备份数据目录，提取与每位好友的互动信息。这里注意，如果微信版本升级过，比如在 Ubuntu 24.04 上安装的是微信 Linux 4.1.11，数据目录里可能会同时存在以前版本的聊天记录。也就是说，新版本启动后会生成新目录，但旧版本的历史记录并不会自动合并过来。做统计时一定要先确认数据目录里到底有哪些历史的版本文件，避免统计结果缺一大截。

第三层是衍生层。将前两层数据合并，通过 pandas 做关联、汇总、派生计算，最终生成一个干净的宽表，供分析阶段使用。

2.3 数据结构设计

数据表结构会直接影响清洗和分析的效率，所以我比较重视字段设计。核心表结构如下：

这个结构基本覆盖了后续分析所需的全部维度，也是典型的数据分析宽表形态。实际用的时候可以按需增减字段，但核心思路是“把原始数据拆成可独立分析的最小粒度”。

2.4 数据采集的合规红线

这里必须提醒一句。网上有不少“微信好友数据分析”的教程，走的是网页端或客户端接口自动化的路径，通过模拟协议一次性批量拉取好友列表。诚然，自动化获取的字段更全、速度也更快，但它在三个方面存在明显风险：

• 稳定风险：这类接口与官方客户端实现原理不一致，官方一更新协议，脚本就崩，维护成本极高；
• 合规风险：自动化脚本触碰了服务条款的边界，一旦被识别，轻则功能受限，重则账号被限制；
• 隐私风险：一旦脚本出错，可能把个人信息发送到错误的目标地址，造成无法挽回的泄露。

所以我的建议很明确：个人分析项目优先采用半自动 + 手工登记的方式，数据量不大时效率足够。如果确实需要自动化，也要当项目试点来设计，并做好账号风险的预案，而不是在正式账号上直接跑。

3. 数据清洗与特征工程：让“脏乱差”的好友信息变得可分析

3.1 重复值与缺失值处理

数据采集完成后，我第一时间用 pandas 做了数据体检，主要检查三个问题：重复、缺失、异常值。

重复值处理比较简单。因为登记时是按标签维度整理的，同一个好友可能被登记到“同事”和“项目组”两个标签下，导致出现重复行。我直接基于 remark 和 nickname 做去重逻辑，保留第一个出现的记录，同时把标签合并起来：

python复制import pandas as pd

df = pd.read_csv('friends_raw.csv', encoding='utf-8-sig')
df['remark_key'] = df['remark'].fillna(df['nickname'])
df = df.sort_values('remark_key').drop_duplicates(subset=['remark_key'], keep='first')

缺失值就需要分字段处理了。地区缺失和签名缺失比较常见，处理策略是：地区缺失保留为“未知”，签名缺失直接置为空；性别缺失统一填 unknown，不影响后续统计；添加年份缺失则根据聊天记录里的最早互动时间反推一个近似年份。

3.2 地区字段的归一化技巧

地区字段是最典型的脏数据来源之一。同一个城市，有人写“浙江杭州”，有人写“杭州”，还有人写“浙江省杭州市”。如果不做归一化，统计结果会被拆得七零八落。

我用了一个两层方法。第一层，把字符串拆出省和市：

python复制def split_region(text):
    if pd.isna(text) or text == '':
        return '未知', '未知'
    text = text.replace('省', ' ').replace('市', ' ')
    parts = text.split()
    if len(parts) >= 2:
        return parts[0], parts[1]
    return parts[0], parts[0]

第二层，对常见简称建一个映射表，把“豫”“粤”“沪”“江浙沪”这类简称归一到标准省名。映射表不需要很全，覆盖 80% 的数据就够用，剩下的归到“其他”即可。

3.3 互动特征构建

有了聊天记录备份的互动数据，我们就可以构造几个高价值的派生特征。

首先是活跃度等级。我按照“最近 30 天是否互动”和“累计聊天条数中位数”两个维度，把好友分成四类：

其次是社交密度。如果某位好友同时出现在我多个标签里，说明这个人的社交连接很可能具有跨场景属性。我用标签数量作为社交密度的近似指标。标签越多，说明这个人在你生活中扮演的角色越多元。

最后是沉默期。用当前日期减去最近互动日期，得到一个时间差，按天存储。这个字段在做触达策略时很有用，比如判断哪些老友值得主动恢复联系。

3.4 数据校验

清洗完数据以后，一定要做一次完整性校验，否则后续图表会有各种“哑巴问题”。我做三件事：

• 检查去重后的记录总数与通讯录人数是否一致，误差超过 2% 就返回检查；
• 检查省份分布的 top10 是否合理，如果出现完全超出预期的省份，重点验证是不是解析逻辑出错；
• 检查最近互动时间字段是否有未来时间或异常空值。

我在 Ubuntu 24.04 上跑这套流程时，就发现微信 Linux 4.1.11 的数据目录里包含旧版本聊天记录，而旧版本的备份文件路径和新版本不一致。直接扫描数据目录时，统计出的聊天条数整整少了 40%。后来调整了扫描逻辑，把 data 目录下所有子目录的历史版本文件都纳入统计，数字才恢复正常。这个问题在 Windows 版微信迁移时也容易遇到，建议提前确认路径规则。

4. 分析实施与可视化：六张图讲清楚我的社交关系

清洗干净后，分析阶段就顺畅多了。我最终用六张图把社交关系讲清楚，这里挑核心的几张展开说明。

4.1 好友总量与添加年份分布

第一张图是好友数量随时间变化的曲线。横轴是添加年份，纵轴是该年新增好友数。这张图能非常直观地看出社交增长的关键节点。

我的数据显示，2018 年是新增好友的峰值年份，这与当年参加行业大会的时间点完全吻合。2020 年有一个明显的低谷，基本对应社交活动骤减的时期。这条曲线不仅仅是数字，它能让我重新复盘“社交增长驱动因素”——线下活动是最大来源，而不是线上内容引流。

4.2 地域分布与城市热力

第二张图是地域分布。我用 pyecharts 的柱状图和地图做了两层展示：柱状图看省份排名，地图看城市热力。

pyecharts 地图展示需要先做省份名称的标准化。比如“广西壮族自治区”要归一成“广西”，“内蒙古自治区”要归一成“内蒙古”，否则地图上很多区域会变成空白。归一的逻辑可以在前面提到的映射表基础上再扩展一层自治区的映射。

我最终得到的结果是：同城好友占比 47%，邻近省份占比 30%，异地好友占比 23%。这个数据直接推翻了我“自己认识很多外地朋友”的感觉——实际上社交半径非常有限。

4.3 标签结构与群组关系

第三张图是标签结构。由于原始标签比较零散，我把标签按用途聚类成几大类：工作类、学习类、生活类、社群类、强关系类。然后画一张旭日图，从大类到二级标签逐层展开。

这张图的洞察价值很大。我发现自己整理得最详细的是“工作类”标签，二级标签超过 20 个；但“生活类”标签几乎空白，连家人和亲戚都没有单独分组。这说明我的标签体系是“职业性社交工具”，而不是个人关系管理工具。

4.4 聊天活跃度与关系分层

第四张图是活跃度分层图。这个分析在所有图表中最直接，也最容易产生行动结果。

我把四类好友的数量和占比做了统计，结论是：高频互动好友只占 6%，稳定关系占 18%，低频占 32%，沉默好友占 44%。也就是说，虽然我微信好友超过 1200，但真正有互动基础的关系不足四分之一。

再用词云可视化高频好友的备注名，会看到备注带有明显的工作属性，比如“某总监”“某老师”“某运营”。这进一步验证了标签体系的结论——社交关系高度职能化。

4.5 共同好友关系网络初探

最后一张图是共同好友的关系网络。数据可以利用我们已经构造好的标签和群聊信息，把共同出现频次高的好友连成关系线。pyecharts 的 Graph 图可以直接实现。

这张图构建时注意两个点：一是不要把所有好友都画进去，先筛选出“至少出现在 2 个标签中”的节点，否则图会密密麻麻什么都看不出来；二是边的权重统一用共同标签数量，这样关系强弱的含义更清晰。

跑出来以后，我的关系网络呈现出明显的“星型结构”——少数几个核心节点连接了大量好友，这些核心节点通常都是工作伙伴。这个现象在社交网络分析里很常见，但真正在自己数据上看到时，冲击力还是很大的。

5. 从数据里读出的结论与三个“反直觉”发现

数据分析如果只停留在画图层面，价值会打很大折扣。真正的乐趣在于从图表里读结论、修正直觉。这次我至少有三个“反直觉”的发现。

5.1 “好友多”不代表“关系多”

1200 个好友，听起来社交资产丰厚，但活跃度分层数据很无情：高频互动关系只有 6%，沉默关系接近一半。这意味着社交网络的规模增长并没有带来等比例的关系深度提升。很多“好友”只是通讯录里的一个条目，并没有真正的互动基础。

这个发现改变了我后续的社交策略：与其四处扩张好友数，不如重点维护高频关系，同时有计划地激活低频关系。

5.2 地域集中程度超过预期

七成好友集中在同城及邻近省份，这与“微信连接全国”的直觉完全相反。原因其实很好理解：微信里的关系大多从线下场景产生，而线下的地理半径天然有限。对做同城生意或本地服务的人来说，这个数据很有参考价值——如果我的好友结构是这样，那么面向更广泛地域的内容投放可能就要调整思路。

5.3 沉默好友的画像往往很有规律

对沉默好友做一次特征对比后发现，他们有三个共性：通过群聊添加、没有进行过备注修改、标签为空白。也就是说，我在群聊里加的、又没有及时做二次备注的好友，最终大概率都会进入“沉默区”。

这可能不算严格意义上的因果关系，但“入群后没有沉淀关系”的模式确实是社交维护的小坑。能得出的行动建议很朴素：加完好友后，立刻补备注、打标签，关系才有可能被后续生活引动。

6. 实操避坑清单：中文乱码、Excel 兼容性与 Linux 环境

6.1 matplotlib 中文显示与 Linux 界面渲染发虚

项目中我一开始用 matplotlib 做图表，第一版就踩了中文显示的大坑。Windows 下跑得好好的，到 Ubuntu 24.04 上，所有中文字体变成方块。原因是系统缺少中文字体包，matplotlib 默认字体里没有 CJK 字形。

解决方案是安装中文字体并重新设置字体参数：

bash复制sudo apt install fonts-noto-cjk

然后代码里指定：

python复制import matplotlib.pyplot as plt
plt.rcParams['font.sans-serif'] = ['Noto Sans CJK SC']
plt.rcParams['axes.unicode_minus'] = False

如果做完这两步还是发虚，大概率是字体缓存问题，重启 Jupyter kernel 或者清空 matplotlib 缓存目录重新加载就能解决。另外，微信 Linux 4.1.11 在 Ubuntu 24.04 上还有一个很有意思的现象：微信界面中文显示虚化模糊，字体边缘发虚，不影响数据本身，但会让人误以为分辨率或显卡驱动有问题。实际上这是软件自身渲染问题，调整系统的字体抗锯齿设置或更新版本即可。这和我们做数据分析关系不大，但如果你在同一个环境里操作，很容易被这种视觉问题干扰，以为是自己代码导致的字符编码出错了。

6.2 pandas 导出 Excel 的兼容性坑

分析完成之后，我习惯把结果导出成 Excel 给团队看。pandas 的 to_excel 方法有几个常见坑：

第一，默认引擎 openpyxl 对合并单元格和格式支持有限，如果后续要人工筛选，最好用 xlsxwriter 引擎，它支持设置列宽、冻结窗格等操作。

python复制with pd.ExcelWriter('friends_report.xlsx', engine='xlsxwriter') as writer:
    df.to_excel(writer, index=False, sheet_name='friends')

第二，Excel 在读取 CSV 时默认按系统区域设置解码，如果你用 UTF-8 保存的 CSV 直接拖进 Excel，中文大概率会乱码。解决办法是导出时加 BOM 头：

python复制df.to_csv('friends.csv', encoding='utf-8-sig', index=False)

这个细节在团队协作时特别重要，能省去很多“为什么我打开是乱码”的沟通成本。

6.3 个人数据安全保护措施

最后，隐私安全必须单独强调。数据分析报告的原始数据包含个人昵称、备注名、地区、互动频率等高度敏感信息，所以我在项目里做了三层保护：

第一层，原始数据表只保存在本地目录，并加入 .gitignore，绝不进入版本仓库；

第二层，报告中所有图表连续列都不显示真实昵称，只展示统计聚合结果。比如关系网络图的节点用“用户A”“用户B”替代，地域图只显示省份聚合；

第三层，如果要在博客或社区分享分析结论，我会先对数据进行脱敏处理，再配一份最小化的模拟数据脚本，让读者可以复现流程而不触碰真实隐私。

做一次项目已经够复杂，不需要再用隐私泄露给项目增加风险。

最后的一点点经验

整个项目从开始到成稿，我前后花了两个完整的周末。回头复盘，最值得推荐的并不是某张图或某个特征工程技巧，而是“先把目标想清楚再动手”的习惯。有了明确的产出清单，中间再遇到微信 Linux 版界面发虚、旧版本聊天记录路径不一致、pyecharts 地图省份名称对不上这些幺蛾子，都能快速判断“这是不是影响主线”的问题，而不是被带着跑偏。

如果你也想做类似的项目，我的建议是：不要一开始就追求完美，先用最小数据集跑通全流程。哪怕只整理 30 个好友的数据，把清洗、分析、可视化跑一遍，再扩展数据量。这个过程会让你对微信好友数据的基本结构和分析难点有一个非常直观的感知，后续做扩展就自然顺畅很多。