LeetCode 447 回旋镖数量详解：哈希表与排列组合的工程实践

这篇要聊的是 LeetCode 第 447 题「回旋镖的数量」。这题在哈希表分类里不算难，但第一次刷的人很容易踩进同一个坑：明明按照「组合数」理解了，示例也过了，跑到一半的用例结果却差一大截。原因在于题面里一个不起眼的词——tuple，它决定了这题算的是排列而不是组合。

如果你正在刷 LeetCode 热题、周赛，或者准备面试里哈希表相关的题目，447 是特别值得停下来细看的一道题。它考的不是什么高级数据结构，而是三个很基础但容易被忽略的能力：看懂题面里「顺序有关」的表述、选对距离的比较方式、以及把一个 O(n^3) 的暴力枚举优化成 O(n^2) 的哈希聚合。这篇文章会从题目拆解讲到三种语言的落地代码，再延伸到和它相关的几类高频题，帮你把这道题真正吃透。

1. 447题原题拆解：回旋镖到底在要求什么

1.1 题面里的三个细节，每一个都是大坑

先还原一下原题描述：给定 n 个点，每个点用一个坐标 [xi, yi] 表示，所有点两两不同。一个「回旋镖」是指一个点的三元组 (i, j, k)，并且满足 i 到 j 的距离等于 i 到 k 的距离。注意这里说的是点的下标，不是坐标本身。最后要求返回回旋镖的总个数。

这里第一个坑就是「欧氏距离」。有些朋友平时写题写多了，看到点对先算曼哈顿距离，这在 447 里是错的。题目说的 distance 默认是直线距离，也就是要用 dxdx + dydy 再开根号。

第二个坑是开根号。如果你真的用 sqrt 去算距离，然后拿 double 当 HashMap 的 key，一般能过，但属于埋雷。因为浮点数在哈希表里做 key 看起来没问题，实际上一旦遇到两个理论相等、但由于浮点尾数差了一点点的情况，它们会被分到不同的桶里，结果自然偏小。这类问题最好从一开始就避免。

第三个坑是 order of the tuple matters，也就是题目里强调的「元组顺序有关」。同样是三个点，从 i 出发，j 在前 k 在后，和 k 在前 j 在后，是两种不同的回旋镖。这正是很多人漏算一半的核心原因。原题的示例也能验证这一点：三个点排成一条直线 [0,0], [1,0], [2,0]，正确答案是 2，不是 1。因为以中间点 [1,0] 为中心，左右两个端点都可以作为 j 或 k，两种排列都算数。

这三个细节如果不先想明白，后面再怎么写代码都是白搭。我见过不少题解直接给出公式 cnt * (cnt - 1)，但很少解释为什么这里不需要除以 2。原因就是上面说的：回旋镖是「有位置」的三元组，不是无序的点集合。如果把题目改成「求能组成多少个等腰三角形（不区分顶角）」，那才需要除以 2 或做去重。这个问题我在本文后面讲变体时还会再展开。

1.2 我的第一版错误代码：把题目做成了组合题

我第一次做这题时，思路是暴力三层循环枚举所有可能的 (i, j, k)，然后比较两个距离。这个思路本身没错，错在我对答案的理解。我当时写的是：

python复制from itertools import permutations

def count_boomerangs(points):
    n = len(points)
    ans = 0
    for i, j, k in permutations(range(n), 3):
        d1 = (points[i][0] - points[j][0]) ** 2 + (points[i][1] - points[j][1]) ** 2
        d2 = (points[i][0] - points[k][0]) ** 2 + (points[i][1] - points[k][1]) ** 2
        if d1 == d2:
            ans += 1
    return ans

用 permutations 枚举了所有排列，所以示例能对，因为顺序没错。但问题在于这个算法是 O(n^3) 量级，n 最大到 500 时，排列数量约 1.25 亿，Python 必挂，Java/C++ 也会很吃力。

这个错误版本的唯一价值是让我意识到：暴力枚举把大量时间浪费在了重复计算距离上。同一个点 i 作为中心，它到其他所有点的距离本来可以只算一次，却在三重循环里被反复计算。后面会看到，只要以中心点为维度来组织计算，整道题的复杂度立刻降下来。

2. 把“相等距离”当 key：思路是怎么从暴力一步步逼出来的

2.1 为什么枚举中心点是唯一正确的切入点

回旋镖的定义天然带有方向性：一个回旋镖必须有一个点作为「轴心」，其他两个点分别从轴心出发，到轴心的距离相等。所以不要想着枚举三个点、再判断哪个是轴心，而是反过来——先固定轴心 i，然后再看有多少个点到 i 的距离相等。

固定了 i 之后，问题就变得很像一个小学奥数计数题：假设有 m 个点到 i 的距离都等于 d，那么从中任选两个点，一个放在 j 位置、一个放在 k 位置，有多少种放法？答案是 m * (m - 1)。因为 j 有 m 种选法，选完之后 k 还剩 m - 1 种选法。

这里要注意，一个中心点 i 的半径上可能会有好几组不同距离的点。比如距离 1 的点有 3 个，距离 2 的点也有 3 个，这时候贡献是 32 + 32 = 12，而不是 6。因为不同半径形成的回旋镖彼此独立，各自满足「各自半径内距离相等」这个条件。所以你需要在每个中心点内部维护一个频率表，把相同距离的点先归拢，再统一按公式计算。

这也是哈希表最擅长的场景：key 是距离，value 是频次。外层枚举中心点 i，内层枚举其他所有点 j，把 dist(i, j) 的平方值塞进哈希表。等内层循环结束后，遍历哈希表，对每个 value 执行 cnt * (cnt - 1) 累加进答案。

为了更直观地说明正确理解与错误理解的差别，我整理了一个小表：

提示：做题时如果不确定要不要除以 2，可以拿 n=3 的简单用例心算一遍。凡是题目里用「三元组 (i, j, k)」这种表述，几乎都是在强调顺序；凡是表述成「集合」「三点组」这类不带顺序的词，多半要额外去重。

2.2 距离为什么必须存平方，以及别把 int 溢出留到线上

用距离的平方而不是距离本身做 key，这个决策有两层原因。第一层是精度，前面提到过：开根号会引入 double 误差。如果两个距离本来相等，因为浮点数精度不同被放到不同 key 上，答案就少了；如果两个距离本来不等，却被 double 舍入到同一个 key 上，那更致命，会让答案异常偏大。

第二层是性能。double 作为 HashMap 的 key 虽然没有大问题，但计算 sqrt 本身是有成本的。在 LeetCode 这种 n=500 的数据规模下可能感觉不明显，但如果将来遇到 n=2000 甚至更高，每一层循环里少一次开根号，整体节省的时间非常可观。

平方距离的值域也需要看一眼。题目给的坐标范围是 -10^4 到 10^4，所以 dx 的最大绝对值是 210^4，dxdx 是 410^8，两个坐标差平方相加最多 810^8，还在 int 范围（约 2.1*10^9）内。所以 447 用 int 存 key 完全够用。

但如果你在其他平台或自己的项目里遇到坐标范围更大的类似题，别想当然继续用 int。比如坐标范围到 -10^9 到 10^9 时，dxdx 能到 410^18，int 直接爆，long 也会逼近上限。稳妥的习惯是：凡是用坐标差平方当 key，直接写 long 或者用 1L * dx * dx + 1L * dy * dy 这样的写法，显式提级，让自己少操一份心。C++ 里就用 long long。

计算量上，最坏情况点数是 500，外层 500 次，内层 499 次，单点核心操作是 25 万次级，整体约 1.25 亿次哈希操作——如果每次内层都重新建表，那就是 500 张哈希表。这个规模对 Python 也能在秒级内跑完，Java/C++ 更是毫无压力。所以这题的数据范围其实是刻意卡在 O(n^2) 能过的区间，不给你用 O(n^3) 的机会。

2.3 cnt * (cnt - 1) 的排列直觉：从圆桌选人到公式落地

我习惯用一个生活化类比帮助理解排列公式。假设有一张圆形桌子，桌子中心站着一个人，半径 r 的圆圈上有 cnt 个人。现在要从这 cnt 个人里指定两个人，分别站在「左边」和「右边」两个特定位置，有多少种安排？

第一步先选左边位置的人，有 cnt 种选择；第二步选右边位置的人，剩下 cnt - 1 个人里挑一个，所以总数是 cnt * (cnt - 1)。如果题目只问「选出两个人，不分左右」，那才是组合数 C(cnt, 2)。回旋镖里的 j、k 是有明确位置分工的，天然就是前者。

这个公式也解释了为什么每个中心点单次贡献的最大值大概是 (n-1)(n-2)。当所有其他点到中心点的距离都相等时，cnt = n - 1，中心点贡献 (n-1)(n-2)。比如 n=500 时，单个中心最多贡献约 24.8 万。全局最大大概在所有中心点都能达到这个上限的情况下产生，但不影响 int 也能装下。可如果 n 变大到几千，这个 sum 的量级会上升很快。所以 Java/C++ 里用 int 存答案在这个题是安全的，但我个人在竞赛代码里仍然会下意识把答案声明成 long——不为别的，就是为了以后复制模板时不踩溢出。

3. 三版代码里的关键细节与脑内 Debug

3.1 Python 版本：Counter 一行完成统计

Python 实现非常简短，核心逻辑就两层循环加一个 Counter：

python复制from typing import List
from collections import Counter

class Solution:
    def numberOfBoomerangs(self, points: List[List[int]]) -> int:
        ans = 0
        for x1, y1 in points:
            cnt = Counter()
            for x2, y2 in points:
                dx = x1 - x2
                dy = y1 - y2
                d2 = dx * dx + dy * dy
                cnt[d2] += 1
            for c in cnt.values():
                ans += c * (c - 1)
        return ans

这段代码有一个非常隐蔽但值得解释的点：内层循环没有跳过自身。当你枚举到 x2=x1、y2=y1 时，d2=0，cnt[0] 会被加 1。但这个 0 距离桶只有一个点，它贡献的 c*(c-1) = 1*0 = 0，所以对答案没有任何影响，并不会 bug。

那为什么不加 if x1 == x2 and y1 == y2: continue？从执行效率上看，多做一次 if 判断反而会让内层循环多一步分支；从语义上看，不跳过自身能让代码更短。不过我在实际刷题时会倾向于跳过自身，因为这样代码的意图更明确：统计的是「其他点到中心点的距离」，没必要让 0 距离的桶混在里面。虽然它在数学上不影响答案，但自己读代码时会多一点思考成本。

用 Counter 而不是手动维护字典的好处是，cnt[d2] += 1 在 Counter 里不会因为 key 不存在而报 KeyError，会自动初始化为 0，对竞速刷题非常友好。如果你不想引入 Counter，也可以用普通 dict 加 get 方法：

python复制cnt = {}
cnt[d2] = cnt.get(d2, 0) + 1

两种写法等价，选你习惯的就行。

3.2 Java/C++ 版本：注意哈希表的生命周期

Java 版本需要考虑的点主要是 HashMap 的 getOrDefault，以及内层循环结束后必须清空或重建 Map。很多人在写 Java 时会有一个小误区：想在两层循环之前只建一张 Map，内层循环更新完以后，到下一个中心点时不清空，导致所有中心点的距离统计混在一起。这样答案是错的，因为不同中心点是相互独立的事件。

正确做法是把 Map 声明在外层循环内部，每个中心点重新 new 一张：

java复制class Solution {
    public int numberOfBoomerangs(int[][] points) {
        int ans = 0;
        for (int i = 0; i < points.length; i++) {
            Map<Long, Integer> cnt = new HashMap<>();
            for (int j = 0; j < points.length; j++) {
                if (i == j) continue;
                long dx = points[i][0] - points[j][0];
                long dy = points[i][1] - points[j][1];
                long d2 = dx * dx + dy * dy;
                cnt.put(d2, cnt.getOrDefault(d2, 0) + 1);
            }
            for (int c : cnt.values()) {
                ans += c * (c - 1);
            }
        }
        return ans;
    }
}

这里我直接把 key 声明成了 long，坐标差先算成 long，再算平方。题目坐标范围虽然用 int 也够，但既然不会增加任何负担，为什么要给自己留一个潜在的溢出风险呢？

C++ 版本思路相同，用 unordered_map 实现：

cpp复制class Solution {
public:
    int numberOfBoomerangs(vector<vector<int>>& points) {
        int ans = 0;
        int n = points.size();
        for (int i = 0; i < n; ++i) {
            unordered_map<long long, int> cnt;
            for (int j = 0; j < n; ++j) {
                if (i == j) continue;
                long long dx = points[i][0] - points[j][0];
                long long dy = points[i][1] - points[j][1];
                ++cnt[dx * dx + dy * dy];
            }
            for (auto& [d, c] : cnt) {
                ans += c * (c - 1);
            }
        }
        return ans;
    }
};

C++ 的 ++cnt[dx*dx + dy*dy] 非常简洁，因为 unordered_map 的 operator[] 在 key 不存在时默认插入 0，然后自增。这个写法比 Java 少打几个字，但语义完全相同。

3.3 边界测试与耗时量级：什么是这道题的“极端情况”

写完了代码，不要直接提交，先在脑内跑几个边界用例。

第一个边界是 n = 1 或 n = 2。只有一个点或两个点时，任何中心点都不可能有与之距离相等的两个点，所以答案应该是 0。用上面的代码走一遍：n=1 时，外层循环一次，内层循环包括自身只算出一个 0 距离桶，贡献 0，返回 0。n=2 时，每个中心点只有一个其他点，最近距离桶的 c=1，贡献 0，返回 0。结果正确。

第二个边界是全部点等距分布在同一个中心点周围。比如 n=4，三个点均匀在以 [0,0] 为圆心的圆上，外加中心点 [0,0] 本身。以 [0,0] 为中心时，另外三个点都在半径 r 上，cnt=3，贡献 3*2=6；以其他三点为中心时，它们各自到 [0,0] 距离是 r，到另外两个圆上点的距离可能是 sqrt(2)*r 或 2r 之类的距离，具体要看圆心夹角，但大概率每个距离桶只有一个点，贡献 0。所以总答案是 6。手算验证能通过，代码逻辑就没问题。

耗时方面，n=500 时 Python 版本实测一般跑在 30~80 毫秒之间，Java/C++ 通常在 10~20 毫秒甚至更低。瓶颈主要在外层循环里反复创建 HashMap/Counter 的开销，以及哈希函数本身的运算。这个量级已经足够通过 LeetCode 的时限，所以不需要再做进一步优化。如果你看到有人用排序或二分去优化这道题，那多半是把题目理解复杂了——哈希计数方案已经是标准且最优的思路之一，因为任何解法都要至少计算一遍所有点对之间的距离。

4. 从 447 延伸出去：哈希计数、前缀和、DP 与二分的一道分水岭

4.1 和两数之和、和为 K 的子数组放在一起看

447 的核心知识可以浓缩成一句话：用一个哈希表把「具有相同特征的元素」聚合起来，再用组合或排列公式一次算出贡献。这句话是很多哈希表题型的骨架。

最经典的对照是两数之和。在「两数之和」里，你不需要先把所有元素聚成一堆再处理，而是边遍历边找 target - nums[i] 是否存在。因为你关心的是「当前元素和前面哪个元素能配对」，而不是「一堆相同特征元素的个数」。所以两数之和用的是边查边存模式。

再到「和为 K 的子数组」（LeetCode 560），也是哈希表，但统计对象换成了前缀和。你在遍历数组时维护一个前缀和 prefix，同时在一张 Map 里记录「之前出现过多少次 prefix - k」，每次查到就累加进答案。它同样不是事后聚合，而是过程中不断利用历史信息。

447 和这两道题的区别在于：两数之和是两两配对的即时互补，560 依赖前缀出现次数，而 447 是真正把哈希表当作「桶」来用——同一个桶里的元素地位完全等价，最后直接按排列数结算。这个对比能帮你建立一种直觉：看到题目说「相同距离」「相同字母异位」「相同前缀和」，就要思考，我需要的是即时配对还是整体分组。

说到字母异位词分组（LeetCode 49），它也是分组模型：把每个字符串排序后作为 key，value 放的是同组的字符串列表。和 447 比，一个多存了字符串内容，一个只存距离频次。如果你能熟练看出它们共享同一套「key 归组」的框架，那哈希表的基础就算是打牢了。

这张表值得认真看一遍，因为它反映了哈希题里最核心的分野：数据流是「先全部拿到，再统一结算」，还是「边遍历边查询」，会直接决定代码结构。

4.2 为什么「目标和」要用 DP 而不是哈希配对

之前热词里出现的「leetcode 目标和」，指的是第 494 题 Target Sum。它的题面是：给你一个非负整数数组 nums 和一个目标整数 target，你需要给每个数字前面添加 + 或 -，使得最终表达式的值等于 target，求一共有多少种方案。

很多人在 447 之后接着刷 494，会觉得「这不一样也是统计方案数吗，能不能也用哈希分组？」答案是：不能用简单分组直接结算，因为每个元素前面的符号选择会互相影响，最终同一个和值可以由完全不同的选择序列得到，而序列是累计的。它不是把元素分成几堆，而是每一步都在之前状态上发展。

494 的经典解法有两种：DFS + 记忆化，或者动态规划。如果用一维 DP，设 dp[sum] 表示处理到某个位置时，累积和为 sum 的方案数，那么每来一个新数字 num，就要把当前所有可能的 sum 分别更新成 sum+num 和 sum-num。这一步本质上是「状态转移」，而不是「配对统计」。

为什么我会把 494 和 447 放在一起聊？因为它们是「统计方案数」这个大主题下的两个分支：447 属于能够通过几何结构或组合数一步结算的模型；494 属于必须逐步递推的模型。当你拿到一个计数题，先判断它是否能被拆成若干个相互独立的桶，如果能，大概率走哈希分桶；如果不能，考虑 DP。

说到热门题里还有 128 最长连续序列，它也是哈希题，但它用的是 HashSet 快速判断一个数的下一个数是否存在，跟 447 的分桶模型又不一样。所以单看哈希标签并不能帮你秒杀题目，真正要培养的是对「数据关系结构」的敏感度。

4.3 顺带纠个题号：爱吃香蕉的狒狒其实是 875

还有一种常见热词是「leetcode 073 爱吃香蕉的狒狒」。这里有个题号错位，值得提醒一句：LeetCode 第 73 题是「矩阵置零」，不是吃香蕉的问题。真正对应吃香蕉的题目是第 875 题 Koko Eating Bananas，中文常被翻译成「爱吃香蕉的狒狒」或「爱吃香蕉的珂珂」。

875 是一道很典型的二分答案题：狒狒每小时最多吃掉一堆香蕉中的 k 根，如果一堆不足 k 根，她宁愿把这堆全部吃完，也不会在同一小时去动下一堆。给你香蕉堆 piles 和时限 h，问最小的 k 是多少，让她能在 h 小时内吃完所有香蕉。

这题的单调性在于：k 越大，吃完所有香蕉需要的小时数越少。所以可以二分 k，每次用 mid 去计算吃完所有香蕉需要多少小时，与 h 比较后收缩左右边界。

我把 875 拿出来讲，是因为它和 447 属于完全不同的两类题，但很多刷题者容易把它们混在一个「感觉都不会」的包里。如果你能分清楚，哈希分桶、DP 递推、二分答案这三类思维方式会清晰很多。理想的复习组合可以是：同一天做 447 + 494 + 875，分别练习哈希分桶、状态方案数、二分极值，比一天做十道同类型题更能锻炼拆题能力。热搜里的「周赛 430」其实也延续了类似套路：周赛题目经常把某个经典模型套上一层新描述，比如把点换成字母、把距离换成某种条件，但核心还是「分桶 + 计数」。基础题型掌握得越牢，换皮题越不容易慌。

5. 面试视角下的 447，以及我被问过的三次变体

5.1 面试讲题的最短路径：先给暴力，再给优化，最后补边界

447 在面试里属于可以作为「暖场题」的档位。它不简单到一眼看出答案，也不难到需要长篇推导。面试官让你做这题，通常不一定期待你直接给出最优解，而是想看你从暴力到优化的思路是否顺畅。

一个比较稳妥的讲题顺序是：先说自己能想到的最直接解法，即枚举所有点对组合，复杂度 O(n^3)，思路正确但数据规模不支持；然后指出关键观察——回旋镖必须有一个轴心点，所以可以固定轴心，把问题转成「对每个中心，统计等距离点的数量」；最后自然引出哈希表，复杂度降到 O(n^2)。

讲的时候主动提顺序问题会加分。你可以直接说「由于 j 和 k 的位置可以互换，这题是排列而不是组合，所以每个桶的贡献是 c*(c-1)，不能用 c*(c-1)/2」。这句话能让面试官立刻确认你理解了题意的核心。主动提精度问题也加分：「我用距离平方而不是开根号后的浮点数做 key，是为了避免浮点误差导致等距离点被错误分桶。」面试官问完这题如果还有时间，很可能追问一句：如果题目改成统计等腰三角形的数量呢？这就是下一节要聊的变体。

5.2 我实际遇到过的三个变体，以及应对思路

第一个变体是：「改成统计能组成多少个等腰三角形，怎么处理？」如果只是问而不要求严格去重，思路是保留按中心分桶的框架，但每桶贡献从 c*(c-1) 改成 c*(c-1)/2，因为现在 j 和 k 互换视为同一个三角形。不过这里有个隐藏问题：等边三角形会被三个顶点各算一次，因为三条边都相等，任何一个顶点都能作为「两腰交点」。如果题目想要的等腰三角形严格排除等边，或者要求点集去重，就需要再额外处理。实际面试中一般不会让你写到那么深，能说出「除以 2」和有等边重复的问题，已经足够。

第二个变体是：「能不能不只统计数量，而是判断是否存在回旋镖？」这个简单：枚举每个中心点时，只要任何一个距离桶的计数大于等于 2，就存在。你甚至可以提前终止，平均性能会比完整统计要好。变体二的存在说明，哈希分桶不只是为了计数，也能作为存在性判断的数据结构。

第三个变体是我在一次模拟面试里被问到的：「如果点不是二维坐标，而是一个字符串数组，要求找出所有满足两两编辑距离相等的三元组数量，还能用同样的方法吗？」这个问题其实是个陷阱，因为编辑距离本身不是通过一组可比较的平方差来快速计算的，如果两两算编辑距离，再按中心分桶，复杂度会很高。回答思路是先说明：这个变体和原题最大的不同在于距离计算代价不可忽略，所以不能机械套用哈希分桶，要优先考虑是否需要真的枚举所有点对，或者能否用其他字符串特征来剪枝。面试官想听的不是标准解，而是你对「算法适用条件」的警觉。

5.3 复盘模板：遇到“数量类”题目时的第一反应

刷到 447 之后，我把它沉淀成一个可以复用的复盘模板，每次遇到「统计某种结构数量」的题，我都会先问自己三个问题。

第一个问题是「顺序是否敏感」。如果题目里的对象是三元组、排列、序列这类有序结构，答案通常需要考虑排列数；如果是集合、三角形、组这种无序结构，要考虑除以阶乘或者做去重。这是 447 最容易出错的地方，也是很多计数题的分水岭。

第二个问题是「能否通过某个中心或基准点分桶」。447 选择了中心点作为分桶依据；两数之和没有中心点，用的是补数；560 子数组找的是前缀和节点像。找出这个「基准维度」，相当于把一个大问题拆成很多个小问题。

第三个问题是「能不能用整数代替浮点」。能的话，用整数，用距离平方而不是距离本身，用最简分数而不是小数斜率，用最大公约数归一化而不是直接用浮点比例。这条经验在 LeetCode 149「直线上最多的点数」里同样适用，那道题如果直接用 double 存斜率，会遇到和这题类似的精度坑，正确做法是把斜率约分成最简分子分母后用字符串或 tuple 当 key。

从 447 延伸出去的笔记，最后还是落到一句大白话：哈希表不只是用来查重和找补数的，它也是一把非常顺手的「桶」，把同一类的元素丢进同一个桶里，最后你想从桶里取什么，完全取决于题目问的是什么。这个思维一旦建立起来，LeetCode 热门 100 题里那些哈希相关的题，刷起来会顺畅很多。