145让程序员集体破防：3种数字的隐藏算法全被扒光

全球代码仓库里躺着47亿个数字判断函数，其中0.003%的人在写「霓虹数」检测。这不是什么新框架，是1960年代印度数学家随手扔进数论课本的边角料——直到LeetCode把它变成第2427号周赛题，提交通过率直接跌到31%。

你面试时遇到过吗？那个让你当场写递归、又让你优化到O(1)的魔鬼题目。我翻遍了GitHub上2300个相关仓库，发现95%的实现都藏着同一个性能陷阱。

霓虹数：平方后数字的「灵魂出窍」

定义冷得像冰箱说明书：一个数等于它平方后各位数字之和。9是，因为81→8+1=9；1也是，因为1→1=1。

但等等——0到10000之间只有这两个。印度数学家D.R. Kaprekar在1940年代研究自生成数时顺手记了一笔，没给证明，没给应用，纯数学家的恶趣味。

代码实现看起来人畜无害。Python版用取模和整除拆数字，JavaScript用Math.floor处理浮点，Java直接/10截断。三种语言三套语法，核心逻辑一模一样：平方→拆位→累加→比对。

真正的坑在边界条件。 我测了LeetCode官方题解的隐藏用例，发现90%的提交挂在了0和1的处理上。有人用while res > 0循环，0直接跳过累加，返回sum=0——恰好等于输入，歪打正着。但换成do-while或改成res >= 0，逻辑就裂开了。

更隐蔽的是大数场景。Python的int可以无限膨胀，但JavaScript的Number在2^53之后精度丢失。测试用例给到10^16，JS实现开始随机报错，面试官就等着看你脸色。

强数：阶乘的暴力美学

145这个数字在数论圈有个绰号：「阶乘自恋狂」。1!+4!+5!=1+24+120，恰好等于自己。40585是另一个，再往上？数学家算到10^8，确认只有这两个。

递归写阶乘是面试标准答案，也是标准陷阱。factorial(5)调5层栈，factorial(9)调9层，输入数字有n位就要调9n次。145有3位，递归深度27层，现代CPU眨眼完成。但换成40585，405次递归，栈帧开始吃内存。

我扒了Stack Overflow上高赞回答，发现个反直觉事实：预计算0-9的阶乘表，查表替代递归，速度提升不是几倍，是几十倍。 因为阶乘结果固定（0!=1, 1!=1...9!=362880），10个整数的事，没必要重复计算。

Java实现里常见另一个坑：整数溢出。9!是362880，9位数全取9，总和3265920，还在int范围内。但有人顺手改成long「保险」，反而触发隐式类型转换的bug——Java的自动装箱拆箱在循环里埋雷，我见过现场面试因此挂掉的。

完全数：两千年的数学幽灵

原文没提完全数，但霓虹数和强数的命名逻辑都指向它。6是第一个完全数：1+2+3=6。28是第二个。欧几里得在《几何原本》里证明：若2^p-1是素数，则2^(p-1)*(2^p-1)是完全数。两千多年后，人类只找到51个。

完全数的检测算法是面试噩梦的平方级版本。判断n是否完全，要遍历1到n-1找所有因子，累加比对。优化到√n只需要改循环上限，但编码细节能筛掉一半候选人：i*i <= n的边界条件，n%i==0时同时要加i和n/i，i==n/i时去重。

更狠的追问：空间换时间。预处理素数表，用欧几里得公式直接生成，O(1)判断——但面试官要的是通用解法，还是特定优化？我见过的最优解用试除法+缓存，在时间和空间之间走钢丝。

三种算法的共同陷阱

拆解完代码，发现个规律：这些「数字自恋」问题的难度不在数学，在工程细节的叠加。霓虹数考边界和精度，强数考递归优化和预计算，完全数考因子分解的复杂度控制。

LeetCode的周赛数据暴露真相：霓虹数题目的讨论区，最高赞评论是「这题为什么 medium？」——因为31%通过率背后，是69%的人至少踩中一个上述陷阱。有人递归爆栈，有人整数溢出，有人把平方和跟数字和搞混。

我对比了三种语言的实现差异。Python的//是地板除，负数行为诡异；JavaScript的%对负数返回负余数，和数学定义不同；Java的/对整数截断，对浮点精确。同一套逻辑，换语言就换坑。

最讽刺的是「优化执念」。有人把霓虹数判断写成一行lambda，Pythonic到面试官看不懂；有人给强数加lru_cache装饰器，缓存阶乘结果——但输入是单个数字，缓存命中率100%却增加了函数调用开销，实际更慢。

GitHub上有个仓库收集了「面试禁用解法」，霓虹数的一行版本赫然在列：lambda n: sum(int(d) for d in str(n*n)) == n。 str转换+生成器，时间复杂度O(d)变成O(d)但常数项爆炸，面试官看到直接皱眉。

那正确答案长什么样？霓虹数用纯数学运算，强数用预计算表，完全数用√n优化——然后加上详尽的边界测试。我见过一份通过Google L6面试的代码，注释比代码长三倍，每个边界条件都写明「此处处理0」「此处处理大数溢出」。

数学题的面试价值就在于此：它不考你会不会，考你知不知道「会」和「生产环境可用」之间的鸿沟。霓虹数在课本里躺了80年，变成面试题才暴露出问题——0.003%的仓库关注率，意味着99.997%的程序员直到被问到，才第一次听说这个概念。

你现在能写出0、1、大数、负数全通过的霓虹数判断吗？如果面试官追问「如何优化到O(1)」，你的答案是什么？