LeetCode 202 快乐数：用判环思想与快慢指针破解数字循环

如果你刷题刷到一定量，大概率会有一种感觉：有些题长得像小学数学，真要现场把原理讲透，反而会卡壳。LeetCode 202 快乐数就是这么一道题。它躺在热门100题列表里，标着 easy，解法也很短，但它背后牵扯出来的判环思想，几乎可以无缝移植到链表成环、循环依赖检测、递归死循环排查这些更“高级”的题目里。

题目本身一句话就能说完：给一个正整数 n，每次把它替换成各个位置上数字的平方和。不停地重复这个过程，如果某一次得到 1，它就是快乐数；如果陷入无限循环且永远到不了 1，它就不是快乐数。比如 n = 19 就是标准快乐数，从 19 出发会走出一条到 1 的路径；而 n = 2 则会进到一条循环轨道里，怎么转都回不到 1。

我第一次做这道题时，心里想的是：这还不简单？直接 while 循环套一层平方和计算，等 n 变成 1 就返回 true，不等就是 false。结果一运行就发现不对劲——n = 2 的时候程序直接无限循环了。这恰好点出了这道题真正的考点：你怎么知道它会循环？你怎么判断它永远变不到 1？下面我把这道题的完整拆解过程写出来，包括两种主流解法的思路、证明和代码，以及我在实际刷题中绕过的坑。

1. 透过题面看本质：这不是求值问题，而是判环问题

1.1 用两个例子直观感受“快乐”和“不快乐”

先动手算一个快乐数：n = 19。

第一次平方和：1² + 9² = 82
第二次：8² + 2² = 68
第三次：6² + 8² = 100
第四次：1² + 0² + 0² = 1

到了 1 之后，如果继续做同样的运算，1² = 1，会一直停留在 1，这就是一个稳定的“终点”。

再看一个不快乐的例子：n = 2。

2 → 4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4

可以看到 4 在第十步又出现了。因为每一步的运算规则是确定的，一旦某个数字第二次出现，后面所有数字都会完全复刻上一轮路径，于是进入一个死循环。2 永远也不可能变成 1。

这两个例子合在一起，基本就是整个题目的全貌了：快乐数最终会滑入 1 的自循环；非快乐数最终会滑入某个不包含 1 的循环。题目表面是在问“能不能变成 1”，实际是在问“这个数字变换过程最后会走进哪条循环轨道”。

1.2 无限循环是题面给的最重要提示

很多新手会忽略题面里“也可能是无限循环但始终变不到 1”这句话。它不是在讲故事，而是在告诉你解题方向：必须能识别循环。

如果只会无脑迭代，遇到非快乐数就会卡死在 while 里。测试用例只给几个数的时候还发现不了，一旦把 2、3、4 这类非快乐数塞进去，程序就当场超时。我第一次就是这样，超时后才重新读题，意识到问题核心是“如何判断重复状态”。

这类题的通用解法套路，其实就是一句话：判断一个过程中是否出现了重复状态。重复状态一旦出现，就不可能有未来；反过来说，如果直到变成 1 都还没出现重复，那它就是快乐数。

1.3 状态机视角的建模

把每次“替换为各位平方和”看作一次状态转移，这个题目可以重新描述成一张图：

• 每个正整数是一个节点；
• 从数字 a 连一条有向边到 f(a)，其中 f(a) 等于 a 各位数字平方和；
• 不管从哪个节点出发，沿着有向边走，最终必然走进一个环；
• 如果这个环是 1 → 1 → 1，那么起点是快乐数；如果是其他环，起点不是快乐数。

这就不是一道简单的模拟题了，而是图论里的“环检测”问题。检测有向图里有没有环，最常用的两个手段就是哈希集合和快慢指针。这两个手段正好对应快乐数的两种主流解法，也对应面试官追问时的两个层次。

2. 哈希集合实现：把每一步当成状态去判重

2.1 为什么一个重复状态就能决定整个序列的命运

在确定性系统里，下一个状态完全由当前状态决定。什么意思？当前数字是 89，下一位一定是 8² + 9² = 145；当前数字是 145，下一位一定是 1² + 4² + 5² = 42。中间没有任何随机性。

所以，当某个数字第二次出现时，之后肯定会把第一次出现后的那条路原封不动地再走一遍。比如上面 n = 2 的例子里，4 第二次出现后，后面的路径仍然是 4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4，无限循环。

哈希集合解法就是抓住这一点：每算出一个新数字，先看它以前有没有出现过。出现过，说明已经绕回旧状态，后面必然死循环，直接返回 false；没出现过，就把它记下来，继续算。只有一种情况可以提前结束：当前数字变成了 1。因为 1 的平方和还是 1，它本身是一个自循环终点，再往后也不会出现其他数字。

2.2 C++实现：计算平方和的辅助函数

先写一个最基础的辅助函数，用来求下一位数字：

cpp复制int getNext(int n) {
    int total = 0;
    while (n > 0) {
        int digit = n % 10;
        total += digit * digit;
        n /= 10;
    }
    return total;
}

每次取 n 的最后一位，累加平方，再通过整除 10 去掉最后一位。这个过程反复执行，直到 n 变成 0。注意循环条件是 n > 0 而不是 n != 0，因为整数除法对负数取整的行为在不同语言里有差异，虽然这道题默认输入正整数，但写成 > 0 更保险。

完整的类实现：

cpp复制class Solution {
public:
    bool isHappy(int n) {
        auto getNext = [](int x) {
            int total = 0;
            while (x > 0) {
                int digit = x % 10;
                total += digit * digit;
                x /= 10;
            }
            return total;
        };

        unordered_set<int> seen;
        while (n != 1 && seen.find(n) == seen.end()) {
            seen.insert(n);
            n = getNext(n);
        }

        return n == 1;
    }
};

循环退出就两种情况：要么 n 先变成 1，要么 n 在 seen 集合里重复出现。退出之后如果 n 是 1，说明是真快乐数；否则说明撞上了重复状态，返回 false。

2.3 复杂度说明与哈希表的边界问题

时间复杂度方面，getNext 每次需要遍历当前数字的每一位，60 亿量级的整数也才 10 位，所以单次转换开销是 O(log n)。至于总共转换多少次，由于平方和会快速收敛，状态数量实际上非常有限，整个循环层数有上界，时间复杂度可以按 O(log n) 理解。

空间复杂度则是 O(log n) 量级，因为 HashSet 里记录的是从起点到进环之前的所有状态。如果追求极致的严谨可以讨论得更细，但对面试回答来说，O(log n) 已经是官方解法水平。

我实际写这段代码的时候，有两点体会：

• 不要在一开始就把 n = 1 特殊处理。while 条件是 n != 1，n 本身是 1 时直接跳过循环，最后 return n == 1 返回 true，天然正确处理。
• unordered_set<int> seen 可以换成布尔数组。因为后续我们会在第 4 节证明，运算结果会被限制在 243 以内，所以开一个 bool seen[1000] 也完全够用。用哈希集合更通用，不容易被边界卡到，我通常默认写哈希。

3. 快慢指针写法：更优的空间，更深的原理

3.1 从链表判环到快乐数：同一个模型

如果面试官紧接着问一句“能不能把空间复杂度降到 O(1)”，哈希集合方案就有点吃力了。这时候需要想起 Floyd 判圈算法，也叫快慢指针法。

链表判环的经典场景是：给一条链表，用慢指针每次走一步，快指针每次走两步，如果链表里有环，两个指针终会在环里相遇。这个思路可以原封不动搬到快乐数上，因为前面已经建立了状态机模型：

• 每次 getNext 就是沿着有向边往前走一步；
• 快乐数的轨道是“先一段路径，然后进了 1 自环”，非快乐数的轨道是“先一段路径，然后进了其他环”；
• 慢指针每次调用一次 getNext，快指针每次调用两次 getNext；
• 如果状态轨道里有环，快指针迟早会追上慢指针。

由于 fast 每次多走一步，在环内 fast 相对 slow 的速度是“每轮靠近一步”，所以只要存在环，必然相遇。这也是 Floyd 判圈算法最朴素的理解方式。

3.2 完整代码与核心细节

cpp复制class Solution {
public:
    bool isHappy(int n) {
        auto getNext = [](int x) {
            int total = 0;
            while (x > 0) {
                int digit = x % 10;
                total += digit * digit;
                x /= 10;
            }
            return total;
        };

        int slow = n;
        int fast = n;

        do {
            slow = getNext(slow);
            fast = getNext(fast);
            fast = getNext(fast);
        } while (slow != fast);

        return slow == 1;
    }
};

这里有一个特别容易写错的地方：为什么不能直接 while (slow != fast) 开始循环？

因为初始化时 slow 和 fast 都是 n，两者一开始就相等。如果不用 do-while，循环体会一次都不执行，直接跳到最后的 return slow == 1，那么输入 n = 2 时会错误地返回 false 吗？其实如果直接跳到 return，slow = 2，返回 false，碰巧对非快乐数也是 false，但输入 n = 19 也会返回 false，就错了。所以必须保证“先移动指针、再比较”的语义，do-while 是最自然的写法。

另一种常见写法是把 fast 先走一步：

cpp复制int slow = n;
int fast = getNext(n);

while (fast != 1 && slow != fast) {
    slow = getNext(slow);
    fast = getNext(getNext(fast));
}

return fast == 1;

这种写法也正确，但要多考虑一层：fast 走到 1 之后，再继续 getNext 还是 1，所以可以提前退出。我个人更喜欢 do-while 那一版，逻辑上更接近 Floyd 判圈的标准实现，不容易漏边界。

有一个细节值得解释：循环结束条件是 slow == fast，之后为什么直接看 slow 是不是 1？

因为核心结论是“1 一旦出现，就会永远停在 1”。如果起点是快乐数，快慢指针最终都会滑到 1 上去，相遇时 slow 等于 fast 等于 1。如果起点不是快乐数，它们会在另一个环里相遇，那个环里所有的数都不是 1，所以相遇时 slow 一定不是 1。这个判断方式不需要额外标记，非常干净。

表格对比一下两种解法：

3.3 为什么这种情况下快指针一定追得上

很多人学快慢指针时有一个疑惑：如果环很大，快指针会不会永远追不上慢指针？

不会。假设慢指针进环时，快指针已经在环里的某个位置。之后每次循环，慢指针走一步，快指针走两步，快指针相对慢指针每轮快一步。环的长度是一个有限整数，所以经过至多“环长”轮，快指针必然与慢指针相遇。这个结论与环的长度无关，与入口前的路径长度也无关。

放到快乐数里，这个环长实际上非常短，经典的 4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4 一共才 8 个节点，快指针跑几步就能套圈撞上慢指针。

4. 掉进循环之前的收敛性：数字为什么不可能越算越大

4.1 位数平方和的粗略上界

做这道题的时候，一个绕不开的疑问是：凭什么认为它一定会循环？有没有可能数字越算越大，无限发散，既不变成 1，也不出现重复状态？

答案是不会，因为平方和运算会让多位数快速“缩水”。

关键在于位数。考虑一个 d 位数，最大情况是每一位都等于 9，也就是数字 999…9，这时各位平方和最大：

9² + 9² + ... + 9² = 81d

所以无论 d 位原始数字多大，经过一次平方和运算后，结果最多只有 81d。

4.2 为什么可以放心去记录历史状态

如果 d 比较小，比如 d = 3，三位数最大是 999，平方和最大是 9² × 3 = 243。这个结果仍然是三位数，但数值已经被压缩到 243 以内。

如果 d ≥ 4，可以证明：81d 一定小于这个 d 位数本身。随便代入验证一下，四位数最小是 1000，而 81 × 4 = 324，324 远小于 1000；五位数也是类似，81 × 5 = 405，远小于 10000。既然运算结果比原来的数小，这个数就会不断下降，直到进入三位数的范围。

一旦进入三位数范围，下一步运算结果绝不会超过 243。所以整个游戏的状态空间本质上被限制在一个很小的有限集合里：0 到 243 之间的整数。有限集合里做无限次转移，必然会出现重复状态，出现重复就成环。

这也是第 2 节哈希集合解法为什么一定能终止的理论基础。如果你在面试里把这段讲出来，面试官对你的理解深度会有一个很直观的认识。

4.3 非快乐数的经典循环 4→16→37→…

进了 243 这个有穷状态集以后，所有非快乐数都会殊途同归，滑进同一个经典循环：

4 → 16 → 37 → 58 → 89 → 145 → 42 → 20 → 4

我经常用这个循环来验证自己代码写得对不对：随便拿 2、3、5、6、8、9 这些非快乐数跑，最后都能看到 4 出现，然后开始循环。这个环很有意思，它不是题目设计的，而是平方和运算天然形成的。

如果你在面试里被问“能不能更省一点”，甚至可以直接靠这一点优化：当 n 变成 4 时直接返回 false，因为已经进入了唯一的不快乐环。不过这个优化依赖于你知道“所有非快乐数都进入同一个环”这个结论，需要额外铺垫证明，我建议不要写在主要答案里，当作补充讨论更合适。

5. 多语言实现与最容易踩的细节

5.1 Python 版本与字符串转换的取舍

Python 在 LeetCode 上写起来会很短，核心一行平方和就能搞定：

python复制class Solution:
    def isHappy(self, n: int) -> bool:
        seen = set()

        while n != 1 and n not in seen:
            seen.add(n)
            n = sum(int(c) ** 2 for c in str(n))

        return n == 1

这个写法使用了字符串转换：str(n) 先变成字符序列，再逐个转回整数求平方和。好处是特别直观，坏处是涉及到类型转换，而且每次都要开辟一个新的字符串对象。在 LeetCode 环境下，因为题目输入规模很小，跑起来几乎没差别，日常练习这样写也完全没问题。

但如果想保持和 C++ 版本一致的数值计算思路，可以写一个独立的辅助函数：

python复制def get_next(x):
    total = 0
    while x:
        digit = x % 10
        total += digit * digit
        x //= 10
    return total

这里有一个很容易踩的坑：Python 里 x /= 10 会得到浮点数，可能引发精度问题，必须写 x //= 10，也就是整除。C++ 里 n /= 10 对整数自动取整，所以不需要特别注意，但一旦切到 Python，这就会变成潜在的 bug。我第一次用 Python 写非快乐数用例时，发现程序非常慢且状态混乱，排查半天才发现是除法写错了。

5.2 边界条件与编码注意事项

第一，输入是 1 吗？如果 n = 1，既不需要计算，也不需要判重，直接返回 true。上面写到的两种解法都天然兼容这个情况：哈希版 while 条件直接不满足，返回 true；快慢指针版第一次 getNext 后 slow 和 fast 都会变成 1，循环结束，返回 true。

第二，getNext 函数循环条件应该写什么？写 while (n > 0) 最稳妥。虽然题目输入限定正整数，但函数内部对不断更新的 n 进行计算时，可能在最后一步得到 0，此时直接返回 total 即可。如果循环条件写成 while (n) 效果也一样，只是阅读时不如 > 0 直观。

第三，求各位平方和时不要忘记“先取个位再消位”的顺序。具体操作：当前数字对 10 取余得到最后一位，累加平方；再对当前数字整除 10，相当于删掉最后一位。三步是一个固定套路：digit = n % 10; sum += digit * digit; n /= 10。写多了以后，这个套路会变成条件反射，面试手撕代码时很有用。

第四，哈希集合法在 LeetCode C++ 环境里需要包含 <unordered_set>，但平台已经默认包含常用头文件。如果在自己本地编辑器里跑，要记得补上 include。这不是算法问题，却是很多人本地跑不过的第一原因。

5.3 把判环思路迁移到同类问题

快乐数这道题最值得收藏的原因，是它的解题模型几乎可以直接迁移到很多其他问题上。比如 LeetCode 141 环形链表，如果忘记快乐数的实现细节，也可以参考它的思想：一个快指针、一个慢指针，快走两步慢走一步，能相遇就有环。这和快乐数里快指针每次调两次 getNext 是同构的。

再比如找“数组中重复的数”这类问题，也可以从“是否有重复状态”的角度去思考。还有实际业务里排查死循环，比如某个配置依赖 A 依赖 B、B 又依赖 A，本质上也是检测图里是否存在环。你在快乐数里练出的状态机思维，能迁移到的场景远比想象中多。

这道题我后来在模拟面试里也经常拿来考人。相比于最后答案对不对，我更希望听到对方说出“这个过程一定会循环”这五个字。能把一个看起来随机的数字变换过程抽象成状态机的人，写业务代码时对死循环、递归依赖、重复消费这类问题通常也会敏感得多。至于具体用哈希还是快慢指针，反而是第二步的事了。