大雄行为锻炼第一次看到 LeetCode 990 “等式方程的可满足性”，很多人会在“可满足性”三个字上先紧张一下，以为要上什么 SAT 求解器。其实题目本身给的是 26 个小写字母之间的相等和不等关系，本质上是个离线约束判定问题。核心思路可以用一句话说清楚：先用所有“==”把字母划分成若干个连通集合，再用所有“!=”去检查两端是否被划进了同一集合；只要任何一个不等式的两端已经在同一个集合里，整体就无解。
这道题适合刚学并查集的人拿来练手，也适合刷题数量到一定阶段想系统整理“连通性模型”的人做对比题。它的代码量不大，但非常考察对约束传播的理解，稍不留神就会掉进“边读边判断”的坑里。
1. 题目到底在问什么：从“等式方程”到“集合归属”
1.1 输入格式和输出含义
题目给一个字符串数组，里面每一行都是两种形式之一：
"a==b"：变量a和变量b必须取相同的值"a!=b"：变量a和变量b必须取不同的值
所有变量名都是小写字母，所以最多 26 个节点。问题问的是：是否存在一种对 26 个字母的赋值方案，让所有等式和不等式同时成立。
举个直观例子：
text复制["a==b", "b==c", "c!=a"]
这里有 a==b、b==c，根据等号传递性可以推出 a==c。可第三个约束要求 c!=a，同一个变量不可能同时等于 a 又不等于 a，所以答案是 false。
再看另一个例子：
text复制["a==b", "b!=c", "c==a"]
先看等号：a==b 和 c==a 会把 a、b、c 全连在一起。此时不等号 b!=c 的两个端点已经在同一个集合里，无法满足，答案同样是 false。
1.2 把变量当成图的节点
所有 == 关系都可以看成一条无向边，因为题目里的等号是对称的：a==b 和 b==a 效果完全相同。把满足等号关系的所有点连起来后，图中会出现若干连通分量。一个连通分量里的所有变量必须共享同一个取值，这就是说的“等价类”。
不等号 != 本身不能当作连接节点的边，它更像一个“禁止同集合”的约束。真正需要检查的只是：两个节点是否因为一堆等号关系被强行归到了同一个集合。
于是原问题就转化成了：
- 只考虑所有等号关系，用并查集维护若干集合。
- 遍历所有不等号关系，若端点已经在同一集合，则无解。
- 如果所有不等号都通过了检查，则有解。
为什么这个转化是充分的？因为题面没有限定每个变量只能取 0 或 1，变量的取值域可以看作整数全集。只要两个集合互不相同，就一定能为它们找到两个不同的整数。对集合内来说，所有变量取同一个值；对集合间来说，逐个分配互不相同的整数即可。因此真正会破坏可满足性的矛盾只有一个：某条不等关系连接的两个变量，必须取同一个值。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么看到这题能想到并查集，而不是排序、染色或暴力回溯
2.1 我们维护的其实是动态等价类
很多朋友第一反应是“给每个变量赋一个值，然后验证”。可一旦变量数量稍微上去，回溯搜索的代价就很夸张。而且这里根本没有给出任何具体数值，赋值空间理论上是无限大的，直接搜索没有任何必要。
并查集这个数据结构天然适合维护“等价关系”。它的核心操作是两个：
union(a, b)：把a和b所在的两个集合合并find(a)：查找a当前所在集合的代表元素
等价关系有自反性、对称性、传递性。并查集的每次合并，本质就是在做传递闭包的增量维护。想判断两个点是否已经被若干条关系间接连通，只需查它们的 find 是否相等。
等式方程正好是一次性的离线判定：先不断合并，合并完成后不涉及回退操作。这就是并查集最能发力的场景。
2.2 为什么 DFS / BFS 也能做，但并查集更合适
既然只有 26 个节点，用邻接表建图，再做 DFS 求连通分量，最后检查不等号，确实也可行。对于这个题的输入规模，哪种写法都能通过。
但并查集的好处有两个：
第一，实现简洁。不需要显式建邻接表，不需要维护访问数组，不需要递归遍历所有邻居。并查集的合并和查询都是常数级别的操作，空间只需要一个长度 26 的数组。
第二，可扩展性好。如果题目未来变成动态添加等式关系，或者节点数量达到十万级别，用 DFS 每次重新扫描整个图就非常吃力，而并查集可以稳定支持实时合并与查询。
用生活化一点的类比：DFS 是每次要出行前都重新把整个地图看一遍，规划一条可达路线；并查集则是常年维护一张“谁和谁是一伙的”名单，问两个人是不是一伙的，只需要看名单上的编号。
2.3 单遍扫描为什么容易出错
一个很自然的错误想法是：能不能遍历字符串数组，遇到 == 就合并，遇到 != 就检查两个端点当前是否同集合，如果不同就算通过？
问题在于，后续的等号关系可能推翻之前不等号的判定。
看这个构造：
text复制["a==b", "b!=c", "c==a"]
如果单遍扫描：
- 读取
a==b，合并a、b - 读取
b!=c，此时b和c在不同集合，暂时判定为可以满足 - 读取
c==a，把c合并到a的集合里，导致b和c最终同集合
第 2 步做出的“可以满足”判断在第 3 步之后已经不再成立。单遍扫描没有能力回退之前已经放行的不等号，所以必须采用两遍扫描。第一次循环专门处理所有等号，把所有等价关系固定下来；第二次循环专门处理不等号，此时每个集合已经稳定，调用 find 得到的判定才是最终结果。
2.4 这是不是 2-SAT 问题
类似问题如果变量只有两个取值，比如真或假、0 或 1，那么 a!=b 不能直接只用并查集解决，因为不等号在两个布尔变量之间会形成“恰好相反”的关系，可能还需要检查二分图染色或使用更通用的 2-SAT 建模。
本题不涉及这种限制。变量的取值域不是二值域，而是无限集合。用并查集合并所有等号关系后，每个独立集合一定能分配到与其他集合完全不同的值，所以不等号只有在两端同集合时才会构成矛盾。
3. 核心解法：先合并所有 “==”，再验证 “!=” 的两段式实现
3.1 并查集模板
先用经典模板实现一个 UnionFind。虽然不是所有题目都要求按秩合并，但保留这个习惯可以让模板在更大的数据范围下也足够稳：
python复制from typing import List
class UnionFind:
def __init__(self, n: int):
self.parent = list(range(n))
self.rank = [0] * n
def find(self, x: int) -> int:
# 路径压缩：让当前节点直接指向根，缩短查询链
while self.parent[x] != x:
self.parent[x] = self.parent[self.parent[x]]
x = self.parent[x]
return x
def union(self, x: int, y: int) -> None:
rx = self.find(x)
ry = self.find(y)
if rx == ry:
return
# 按秩合并：让高度小的树挂到高度大的树上
if self.rank[rx] < self.rank[ry]:
self.parent[rx] = ry
elif self.rank[rx] > self.rank[ry]:
self.parent[ry] = rx
else:
self.parent[ry] = rx
self.rank[rx] += 1
其中 find 使用的路径压缩写法是“隔代压缩”：每次让当前节点的父指针跳到父节点的父节点。这个写法避免了递归过深的问题，在 Python 中更稳妥。
3.2 Solution 主逻辑
主逻辑非常简单，两道循环解决问题：
python复制class Solution:
def equationsPossible(self, equations: List[str]) -> bool:
uf = UnionFind(26)
# 第一遍：只处理全部相等关系
for s in equations:
if s[1] == '=':
x = ord(s[0]) - ord('a')
y = ord(s[3]) - ord('a')
uf.union(x, y)
# 第二遍：验证全部不等关系
for s in equations:
if s[1] == '!':
x = ord(s[0]) - ord('a')
y = ord(s[3]) - ord('a')
if uf.find(x) == uf.find(y):
return False
return True
变量名全部是小写字母，所以用 ord('a') 作为偏移量，把字符映射到 0 ~ 25 的整数下标。这里直接减去 ord('a') 能避免 magic number，代码也更易读。
3.3 为什么公式取 s[1] 和 s[3]，不取 s[2]
输入字符串长度固定是 4：
text复制a == b
0 1 2 3
比如 "a==b"，索引 0 是 a，索引 1 是 =，索引 2 是 =，索引 3 是 b。
比如 "a!=b"，索引 0 是 a，索引 1 是 !，索引 2 是 =，索引 3 是 b。
所以判断等号还是不等号，只需要看索引 1 的字符。两个变量分别位于索引 0 和索引 3。
这里有个容易手滑的点：s[1] == '=' 判断的是等号关系。如果写成 s[2] == '='，代码不会越界也不会报错，但会错误地把所有不等式都当成等号处理，结果必然错误。这类索引偏移错误在真实编码中非常常见，建议先自己在本地打印几个示例字符串确认下标。
3.4 本地验证用例
在本地写完可以加一组测试：
python复制if __name__ == "__main__":
s = Solution()
print(s.equationsPossible(["a==b", "b!=c", "c==a"])) # False
print(s.equationsPossible(["a==b", "b==c", "a==c"])) # True
print(s.equationsPossible(["a!=a"])) # False
print(s.equationsPossible(["a==b", "b!=a"])) # False
第一组例子中，a==b 和 c==a 间接让 a、b、c 同集合，不等号 b!=c 无法满足，输出应为 False。
第二组例子三个等号没有任何冲突，输出应为 True。
第三组 a!=a 自己不等自己，直接冲突。
第四组 a==b 合并，但不等号又要求 b 和 a 不同，显然矛盾。
4. 边界条件、耗时体会与提交中的反直觉错误
4.1 常见边界的判定逻辑
这道题的输入范围比较小，但边界条件仍然值得过一遍：
| 输入用例 | 期望输出 | 原因 |
|---|---|---|
["a==a"] |
true |
一个变量等于自己，永远成立 |
["a!=a"] |
false |
任何赋值都不可能让同一个变量不等于自己 |
["a==b", "b!=a"] |
false |
合并后两个变量同集合，但又要求不同 |
["a!=b", "b!=c", "c!=a"] |
true |
给三个变量分配三个不同整数即可 |
["a==b", "b==c", "c==a"] |
true |
三个变量都取同一个值即可 |
["a==b", "b==c", "c!=a"] |
false |
传递性导致 a 与 c 同为集合，不可再分开 |
这些边界主要在考察一点：你的两段式逻辑是否覆盖了“等号传递链”和“自反不等”这两种特殊情况。
a!=a 这种输入其实不需要单独加判断。因为不管第一遍等号关系怎样变化，第二遍检查时调用 find 得到的结果必然是两个相同的值，自然会返回 false。反而写出额外的“如果首尾字符相同”这种特判属于多余代码，增加心智负担。
4.2 代码里最容易翻车的不是并查集，而是“混合处理”
我在一开始尝试这道题时，也犯过直觉性错误：在同一个循环里既处理等号又处理不等号，认为“只要合并时检查一下会不会冲突就行”。后来的失败用例很快就教育了我，前面已经用 ["a==b","b!=c","c==a"] 解释过原因。
这种教训可以泛化成一条规律：如果一组约束中有一部分具有传递性，用来生成连通关系，另一部分只是做最终校验，那么必须先让连通关系完全收敛，再做校验。 尤其是在不等式数量很多的时候，顺序遍历天然带有时序偏差，先读到的不等号可能在后来的合并中失效。
4.3 关于“耗时 100”的实测体会
我在很多刷题笔记里看到标题写着“耗时 100”之类的记录，有人理解为用了 100 毫秒，有人理解为花了 100 分钟想清楚。不管哪种，对这道题来说，单次提交耗时数字并不具备绝对意义。用 Python 实现时，LeetCode 后台在同一份代码反复提交下的波动可能很大，从 80ms 到 160ms 都出现过，单独看某一次的 100ms 没有区别。
真正影响耗时的主要是三个部分：
- 字符串解析：遍历
equations数组时，ord()和字符比较占据一定时间。 - 并查集查找：路径压缩后，单次
find基本接近常数。 - 函数调用开销：在 500 条约束以内，这部分也几乎可以忽略。
如果你的目标是让运行时间更稳定，可以写一个不带 rank 的压缩版，因为本题最大只有 26 个节点，按秩合并的收益并不明显：
python复制class Solution:
def equationsPossible(self, equations: List[str]) -> bool:
parent = list(range(26))
def find(x: int) -> int:
while parent[x] != x:
parent[x] = parent[parent[x]]
x = parent[x]
return x
def union(x: int, y: int) -> None:
rx = find(x)
ry = find(y)
if rx != ry:
parent[rx] = ry
for s in equations:
if s[1] == '=':
union(ord(s[0]) - 97, ord(s[3]) - 97)
for s in equations:
if s[1] == '!':
if find(ord(s[0]) - 97) == find(ord(s[3]) - 97):
return False
return True
这种写法更短，但我个人推荐保留 rank 的版本。原因不是这道题需要，而是刷题时模板保持一致，面对其他数据规模更大的题时能少踩坑。把 find 的路径压缩和 union 的按秩合并固化成一个固定模板，每次使用就不需要临时思考。
5. 从 LeetCode 990 出发：可以迁移到哪些变体题型
5.1 变量范围更大时的映射方式
如果题目不做 26 个字母限制，改成任意字符串变量，比如 "apple == orange"、"banana != orange"，那字符串格式就需要先做分词。操作本身不变，只是不能再用 ord 映射下标，要先给每个出现的变量分配一个数字 ID：
python复制id_map = {}
idx = 0
for s in equations:
left, right = parse(s) # 假装有一个解析函数取出两个变量名
if left not in id_map:
id_map[left] = idx
idx += 1
if right not in id_map:
id_map[right] = idx
idx += 1
然后运行同样的并查集。这里映射的作用是把不规则的字符串输入转换成紧凑的整数下标，否则 parent 数组无法直接使用。
5.2 从“判定型”变成“查询型”题目
990 只需要返回最终是否存在矛盾，属于离线判定。如果把题目升级成：“不断添加新的等式关系，每次添加后询问某两个变量是否一定相等”，这就是一个动态连通性查询问题。
处理方式也很直接：每添加一条 == 就 union；每次查询 x、y 是否相等时，调用 find(x) == find(y)。并查集的在线能力在这里就体现出来了，不需要像 990 这样提前两遍扫描。
如果题目还要求维护每个集合的大小，或者查询某个变量所在集合的全部成员，需要额外维护集合大小数组或链表结构，但核心仍然是并查集。
5.3 如果条件不只是等式和不等式
如果约束条件变成 a > b、b > c，那问题性质就完全不同了。大于号的关系不具备对称性，并且有方向，并查集无法处理；这类问题通常要用拓扑排序或差分约束系统来判断是否存在矛盾。
如果题目变成“每个变量的取值只能是 0 或 1，且给出 a==b 和 a!=b 的关系”，这又会引入二值域的限制，需要借助二分图染色或者 2-SAT 建模，而不是简单的集合合并。
这也是我推荐把 990 放进并查集题单第一个题的原因。它把所有复杂背景都剥掉了，只保留最纯粹的“相等关系等于连通分量”这一层核心。理解透之后，再看其他连通性题目会顺很多。
5.4 与 LeetCode 热门题中连通分量题目的对比
很多 LeetCode 热门 100 题里面，都藏着并查集的身影。比如“省份数量”就是给你若干城市之间的连接关系，问有多个连通分量；再比如“冗余连接”是在一个无向图里找到那条让图成环的边。这些题和 990 一样，本质上都在问同一件事：点与点之间是否存在通过若干条边形成的连通关系。
区别在于：
| 题目 | 核心操作 | 注意点 |
|---|---|---|
| 990 等式方程 | 先合并全部等号，再验证不等号 | 两遍扫描 |
| 省份数量 | 合并所有城市连接边，统计根数量 | 统计时对每个节点 find |
| 冗余连接 | 合并边，发现两端已连通时记录 | 并查集检测环 |
| 账户合并 | 合并同一邮箱地址，再汇总账户 | 需要映射邮箱到 ID |
这些题目之间互相印证后，你对并查集模板的运用会更加得心应手。尤其在做题时先识别“是否属于连通性问题”，比死记硬背题目答案要重要得多。
回到 990 这道题本身，我个人的习惯总结是：看到“相等 / 不等”类约束，第一反应先问自己——等号关系能被传递吗？如果能，那么它就是在生成一个等价类；不等号只是这个等价类上的校验条件。把这一步想清楚，代码自然就落到“先 union，再检查 find”上了。最后再分享一个小技巧：如果第二遍检查时发现输出不对，不要急着怀疑模板，先把所有等号处理后的并查集父亲数组打印出来，看看每个字母实际被归到了哪个根。只要这一步没问题，题目多半就能顺利通过。