微信怎么删好友手写实现原理避坑指南

面试被问底层原理答不上来？别慌，今天拆解微信怎么删好友的手写实现逻辑。

很多开发者觉得删好友就是调个 API，简单得很。错了。这背后涉及状态同步、数据一致性、网络抖动处理。

我在 CSDN 看到不少帖子吐槽，说线上事故就是因为没处理好“删除中”的状态机。

今天不聊玄学，直接上代码，带你用 Python 手写实现一个模拟微信删好友的核心逻辑。

概念速懂：删好友到底删了什么？

在嵌入式或后端开发里，我们常把“删除”理解为 DELETE 操作。但在社交软件里，微信怎么删好友并不是物理删除数据库记录。

它是逻辑删除加状态变更。

想象一下，用户 A 删除用户 B。

A 的好友列表里，B 的 ID 被标记为 deleted=True。
A 发给 B 的消息，B 还能收到（单向阻断）。
B 发给 A 的消息，A 收不到，且 B 会收到“对方已开启好友验证”的提示。
如果 B 也删除了 A，双方关系彻底断开。

这就引出了一个经典面试题：如何保证分布式系统下，A 删 B 和 B 删 A 的状态一致性？

很多人只会写 friend_map[A].remove(B)，这是单线程玩具代码。真正的生产环境，你需要考虑并发。

环境准备：搭建你的“沙盒”

为了演示 手写实现，我们需要一个简单的环境。不需要真的连微信服务器（那是违法的），我们模拟一个内存中的社交图谱。

工具很简单：

Python 3.8+
threading 模块（模拟并发请求）
time 模块（模拟网络延迟）

为什么选 Python？因为语法简洁，能把注意力集中在算法逻辑和状态机上，而不是被语法糖干扰。

如果你用的是 Go 或 Java，思路完全一样，只是语法糖不同。核心在于：锁的粒度和状态机的流转。

核心语法：状态机与锁的艺术

微信怎么删好友的核心难点，在于竞态条件（Race Condition）。

假设 A 和 B 同时发起删除请求，或者 A 删 B 的同时，B 正在给 A 发消息。这时候，如果没有锁，数据就会乱套。

我们用细粒度锁（Fine-grained Locking）来解决。不要对整个数据库加锁，那性能太差。我们要对每一对好友关系加锁。

这里引入一个关键数据结构：FriendshipStatus。

import threading
import time
from enum import Enum
from collections import defaultdict# 定义好友关系状态
class RelationStatus(Enum):NORMAL = 0      # 正常好友DELETED_A = 1   # A删除了B，但B没删ADELETED_B = 2   # B删除了A，但A没删BMUTUAL_DELETED = 3 # 互相删除，关系彻底断开BLOCKED = 4     # 拉黑（本文暂不展开，但逻辑类似）# 模拟数据库存储结构
# key: frozenset({uid1, uid2}), value: dict
class SocialGraph:def __init__(self):self.data = defaultdict(lambda: {"status": RelationStatus.NORMAL, "timestamp": 0})self.locks = {} # 细粒度锁池self.global_lock = threading.Lock() # 用于创建新锁def _get_lock(self, uid1, uid2):"""获取特定好友对的锁注意：锁的Key必须无序，frozenset保证 {1,2} 和 {2,1} 是同一个Key"""key = frozenset([uid1, uid2])with self.global_lock:if key not in self.locks:self.locks[key] = threading.Lock()return self.locks[key]def delete_friend(self, deleter_id, target_id):"""核心逻辑：手写实现删除好友"""# 1. 获取锁lock = self._get_lock(deleter_id, target_id)# 2. 加锁执行with lock:# 获取当前状态key = frozenset([deleter_id, target_id])record = self.data[key]# 模拟网络延迟，增加竞态概率time.sleep(0.01)# 状态机流转逻辑current_status = record["status"]# 如果已经是互相删除，直接返回，幂等性if current_status == RelationStatus.MUTUAL_DELETED:return True, "Already deleted"# 场景1：当前正常，A删除Bif current_status == RelationStatus.NORMAL:record["status"] = RelationStatus.DELETED_Arecord["timestamp"] = time.time()return True, "A deleted B"# 场景2：B已经删除了A，现在A也删除B -> 互相删除elif current_status == RelationStatus.DELETED_B:record["status"] = RelationStatus.MUTUAL_DELETEDrecord["timestamp"] = time.time()return True, "Mutual Deleted"# 场景3：A已经删除了B，重复请求 -> 幂等elif current_status == RelationStatus.DELETED_A:return True, "Already deleted by A"# 其他状态需业务自定义else:return False, "Invalid State"

这段代码里，frozenset 是关键。它确保了 A 看 B 和 B 看 A 操作的是同一个锁。如果用了 tuple，('A', 'B') 和 ('B', 'A') 会是两个不同的锁，这就出大 bug 了。

完整代码示例：并发压力测试

光看代码没用，得跑起来看效果。我们模拟 100 个线程同时操作同一对好友的删除和查询，看看数据会不会崩。

import threading
import time
import randomdef main():graph = SocialGraph()user_a = "user_1001"user_b = "user_1002"# 初始化：两人是好友# 为了测试，我们先手动设置一下初始状态，或者调用 add_friend# 这里简化，直接假设初始为 NORMALresults = []errors = []lock_for_results = threading.Lock()def worker(delete_flag, user_id, target_id):try:if delete_flag:success, msg = graph.delete_friend(user_id, target_id)else:# 模拟查询，虽然本文主要讲删除，但查询也是并发热点# 实际生产中，查询通常走读库，但这里为了演示锁机制，简单处理key = frozenset([user_id, target_id])with graph._get_lock(user_id, target_id):status = graph.data[key]["status"]success, msg = True, f"Status: {status}"with lock_for_results:results.append((user_id, target_id, msg))except Exception as e:with lock_for_results:errors.append(str(e))threads = []# 启动 50 个线程尝试 A 删除 Bfor i in range(50):t = threading.Thread(target=worker, args=(True, user_a, user_b))threads.append(t)t.start()# 启动 50 个线程尝试 B 删除 Afor i in range(50):t = threading.Thread(target=worker, args=(True, user_b, user_a))threads.append(t)t.start()# 等待所有线程完成for t in threads:t.join()# 统计结果mutual_deleted_count = sum(1 for r in results if "Mutual Deleted" in r[2])a_deleted_count = sum(1 for r in results if "A deleted B" in r[2])b_deleted_count = sum(1 for r in results if "Already deleted by A" in r[2] or "Already deleted" in r[2])print(f"Total Requests: {len(results)}")print(f"Errors: {len(errors)}")print(f"Mutual Deleted triggered: {mutual_deleted_count}")print(f"Initial A->B delete: {a_deleted_count}")# 最终状态检查final_key = frozenset([user_a, user_b])final_status = graph.data[final_key]["status"]print(f"Final Status: {final_status}")# 断言：最终状态必须是 MUTUAL_DELETED，且没有错误assert final_status == RelationStatus.MUTUAL_DELETED, "Final state is incorrect!"assert len(errors) == 0, "Errors occurred during concurrency!"print("Test Passed: State consistency maintained.")if __name__ == "__main__":main()

运行这段代码，你会看到 Final Status: RelationStatus.MUTUAL_DELETED。

重点来了：如果没有 lock，或者锁的粒度不对，你可能会看到 Final Status 是 DELETED_A 或者 DELETED_B，甚至数据丢失。这就是手写实现的价值，它让你明白为什么框架里会有那些看似冗余的锁机制。

常见报错：为什么你的代码在服务器上挂了？

在 CSDN 的技术社区里，经常有兄弟问：“为什么本地跑没问题，上线就报错？”

通常有这几个坑：

死锁（Deadlock） 如果你在不同的业务逻辑里，先锁 A-B，再锁 B-C，而另一个线程先锁 B-C，再锁 A-B。恭喜，死锁。 解决方案：永远按照字典序或固定顺序获取锁。比如，永远先锁 ID 小的，再锁 ID 大的。
锁泄漏 在 try 块里加了锁，但在 except 里忘了 unlock，或者没有用 with 语句。 解决方案：强制使用 with lock: 语法，Python 的上下文管理器会自动处理异常时的解锁。
缓存不一致 你改了数据库，但 Redis 缓存没更新。用户 A 删了 B，但 B 的客户端还缓存着 A 是好友的状态，导致 B 发消息不提示“好友验证”。 解决方案：采用缓存旁路模式（Cache-Aside），删除操作先删缓存，再写数据库。或者使用消息队列异步更新缓存。
网络超时重试导致的重复删除 客户端超时，重试请求。如果后端不幂等，可能会触发两次状态变更。 解决方案：如上代码所示，幂等性设计。如果状态已经是 DELETED_A，再次收到删除请求，直接返回成功，不做任何状态变更。