谭康熹回文数判断这题，绝大多数人第一次接触是在 LeetCode 第 9 题，也是面试里出现频率极高的一道基础题。题目本身很简单：给一个整数，判断它从左往右读和从右往左读是否一致。但很多人可能不知道，这道题有一个隐藏的坑——当输入的数字很大时，直接反转整个整数会导致整型溢出。而"半反转法"就是专门为绕开这个坑设计的思路。我最初觉得这题没什么好研究的，直到在一次面试里被问到"你不觉得直接反转整数有风险吗"，才认认真真把这一思路完整过了一遍。这篇就把我整理出来的完整分析、推导过程、边界条件处理和核心代码一起分享出来。
1. 从整型溢出谈起：直接反转的天然缺陷
1.1 常规解法到底哪里不安全
先看大多数人第一反应会给出的解法：把整个整数反转，和原数字比较。
用 Java 写大概是这样的：
java复制public boolean isPalindrome(int x) {
if (x < 0) return false;
int rev = 0;
int temp = x;
while (temp != 0) {
rev = rev * 10 + temp % 10;
temp /= 10;
}
return rev == x;
}
这个方法在数学逻辑上完全成立，对于 121、1221、12321 这类数字都能正确判断。问题出在当输入接近 Integer.MAX_VALUE（2147483647）时，反转后的整数可能超过 32 位有符号整数的表示范围。
举个例子，输入 2147483647，这个数本身不是回文数，但反转过程中会出现中间结果远大于 2^31 - 1 的情况。在 Java 里，int 溢出并不会报错，而是直接做二进制截断，产生一个完全错误的数值。这个错误值一旦和原数比较，结果就没有任何参考意义。
有一种解决方式是改用 long 类型接收反转结果，这样确实能消除溢出风险。但这就产生了一个新的问题：题目明明只要求判断一个 int，却要动用 long，空间和逻辑上都显得不够优雅。更关键的是，如果面试官接着问"如果输入是 long 呢"，这个方案就很难自圆其说。所以说，直接反转的缺陷不是"偶尔溢出"，而是方案边界恰好卡在了数据类型的极限处，属于设计层面的隐患，不是改个细节就能绕开的。
1.2 溢出数值变化的具体表现
为了直观感受溢出，我用 Java 写了一段演示代码，把 2147483647 逐位反转时的中间值打印出来：
java复制int temp = 2147483647;
int rev = 0;
while (temp != 0) {
rev = rev * 10 + temp % 10;
System.out.println("rev = " + rev);
temp /= 10;
}
输出结果里会出现负数，这就是典型的溢出特征。因为在二进制补码表示中，当计算结果超出 int 的最大值，最高位会被解释为符号位，数值瞬间变成一个不可预期的负数。继续执行下去，数值的绝对值、正负号都可能发生跳变，整个过程完全失控。
这个现象说明了一个关键点：在回文数判断这个场景里，溢出不是"偶发故障"，而是"必然结果"。只要数字位数足够多（如 10 位数以上），并且高位数字较大，反转过程中就必然会碰到溢出边界。所以设计算法时，应该从根本上避开"完整反转"这个操作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 半反转法的核心思路：为什么要反转一半
2.1 从"对称性"出发的直觉
回文数的定义是正读反读都一样，比如 1221，前半段是 12，后半段是 21，而后半段反转后恰好是 12，与前半段完全一致。也就是说，判断回文数本质上是判断"数字的前半段"和"数字的后半段反转结果"是否相等。
这里最关键的观察是：既然只需要比较前半段和后半段反转后的关系，那我完全没有必要把整个数字反转完。我只需要把后半段反向拼接到一个新变量里，然后和前半段剩余部分做对比就行了。这就是"半反转"这个名字的由来——不是完整反转，而是只反转二分之一。
用生活中的例子来类比：判断一个人是不是"照镜子对称"，你不需要把整个人转一圈，只需要对比左半边脸和右半边脸的镜像是否一致。数字也一样，后半段的"镜像"就是它逐位反转后的结果。
2.2 终止条件的选择：这个细节决定成败
半反转法的代码结构不复杂，核心问题是：循环到什么时候停下来？
约定：
x为原始输入revertedNumber存储后半段的反转结果
当时我第一反应是"反转一半，那就是反转完 x 位数的一半再停"。但问题是你不知道 x 的位数是奇数还是偶数，总不可能先数一遍位数再开始循环。
后来看官方题解才意识到，最优雅的终止条件不需要单独计算位数，而是利用数值大小关系：
java复制while (x > revertedNumber) {
revertedNumber = revertedNumber * 10 + x % 10;
x /= 10;
}
这个条件的巧妙之处在于：
- 原始数字
x在每次循环后会变短（除以 10） revertedNumber会变长（乘以 10 加末尾数字）- 当
x <= revertedNumber时，说明已经处理到了中间位置
比如 1221：
- 初始
x = 1221，revertedNumber = 0 - 循环第一次：
revertedNumber = 1，x = 122 - 循环第二次：
revertedNumber = 12，x = 12 - 此时
x (12) > revertedNumber (12)不成立，循环停止 - 后半段反转结果为
12，前半段剩余为12，二者相等，判定为回文
再看奇数位数的例子 12321：
- 初始
x = 12321，revertedNumber = 0 - 循环第一次：
revertedNumber = 1，x = 1232 - 循环第二次：
revertedNumber = 12，x = 123 - 循环第三次：
revertedNumber = 123，x = 12 - 此时
x (12) > revertedNumber (123)不成立，循环停止 - 后半段反转结果为
123，前半段剩余为12
这时出现了一个新问题：奇数位数情况下，revertedNumber 比 x 多一位，多出来的那一位恰好是原数字的中间位（数字 3）。所以在最终判断时，需要把 revertedNumber 除以 10 去掉中间位，再与 x 比较：
java复制return x == revertedNumber || x == revertedNumber / 10;
这里两个条件分别对应偶数长度情况和奇数长度情况。
2.3 为什么这个终止条件不会"矫枉过正"
有人可能会担心：万一 x 一开始就小于等于 revertedNumber，循环一次都不执行，判断不就出错了？
这种情况只会出现在个位数输入上。比如 x = 5，revertedNumber = 0，x > revertedNumber 成立，第一次循环后 revertedNumber = 5，x = 0，循环停止。此时 x == revertedNumber / 10（即 0 == 0）成立，判断为回文。这个结果是对的，因为任意个位数都是回文数。
再比如 x = 10，第一次循环后 revertedNumber = 0，x = 1，此时 x > revertedNumber 成立继续循环，第二次 revertedNumber = 1，x = 0，循环停止。此时 x == revertedNumber / 10（即 0 == 0）成立，但 10 不是回文数。
这里就暴露了一个边界问题：如果不在开头排除末尾为 0 的情况，半反转法会误判。所以需要增加前置条件：负数直接返回 false；如果 x 不等于 0 且末位是 0，也直接返回 false。因为回文数的首位和末位必须相同，如果末位是 0，首位也必须是 0，但一个不以 0 开头正常的数字不可能以 0 开头（除了数字 0 本身）。这个判断要在进入算法主体前先做掉。
3. 边界条件与特殊输入：一个都不能漏
3.1 负数、个位数、末尾为 0 的数
把所有边界情况统一列出来，可以整理成一张检查表：
| 输入类型 | 是否回文 | 处理方式 |
|---|---|---|
| 负数（如 -121） | 否 | 负号 '-' 在反转后无法对称，直接返回 false |
| 个位数（如 7） | 是 | 循环后 x == revertedNumber / 10 成立 |
| 0 | 是 | 末位为 0 但自身等于 0，特殊放行 |
| 10, 20, 100 等以 0 结尾的非零数 | 否 | 提前排除，避免误判 |
| 偶数位回文（如 1221） | 是 | x == revertedNumber |
| 奇数位回文（如 12321） | 是 | x == revertedNumber / 10 |
这张表把算法执行前必须处理的情况都概括了。这里的核心思想是：先排除所有不可能成为回文数的输入，再让半反转循环去处理"有潜力"的数字。如果前置判断漏掉"末尾为 0"的情况，实际输出会非常离谱，比如 x = 10 会被判定为回文，因为循环结束后 x 被削减到 0，而 revertedNumber 是 1，revertedNumber / 10 也是 0，两者相等。
3.2 前置判断的完整逻辑
结合上面的分析，完整的算法入口逻辑是：
java复制if (x < 0 || (x % 10 == 0 && x != 0)) {
return false;
}
这里有个值得抠一抠的细节：x % 10 == 0 && x != 0 这个条件本质上是"末位为 0 且自身不为 0"。为什么不能直接写成 x % 10 == 0？因为数字 0 本身是回文数，它的末位也是 0，如果直接排除，就漏掉了 0 这个输入。这可能是整个算法里最容易被忽略的一个点——不是 0 不是回文数，而是 0 太像"以 0 结尾"，容易被误伤。
3.3 奇数位数与偶数位数的分岔点
很多初学者在这里容易卡住：为什么最终判断有两个条件？其实这就是奇偶位数差异导致的。
以 1221（偶数位）为例，循环结束后 x = 12，revertedNumber = 12，两者刚好相等，一对回文数在中间"碰头"了。
以 12321（奇数位）为例，循环结束后 x = 12，revertedNumber = 123，中间位 3 落在了 revertedNumber 的末尾。只要把中间位去掉，也就是 revertedNumber / 10 = 12，就和 x 相等了。
所以最终判断统一写成：
java复制return x == revertedNumber || x == revertedNumber / 10;
这个表达式同时覆盖了奇偶两种情况。如果担心可读性，也可以显式判断"当前位数奇偶"，但完全没必要，两个条件的或运算已经足够清晰。
4. 完整代码实现与逐行解读
4.1 Java 实现（LeetCode 风格）
把上面所有分析整合起来，得到一个可直接提交的完整版本：
java复制class Solution {
public boolean isPalindrome(int x) {
// 特殊情况：
// 1. 负数不可能是回文数
// 2. 末尾为 0 且自身不为 0 的数，首位不可能为 0，所以不可能是回文数
// 3. 数字 0 本身是回文数
if (x < 0 || (x % 10 == 0 && x != 0)) {
return false;
}
int revertedNumber = 0;
while (x > revertedNumber) {
revertedNumber = revertedNumber * 10 + x % 10;
x /= 10;
}
// 偶数长度：x == revertedNumber
// 奇数长度：x == revertedNumber / 10
return x == revertedNumber || x == revertedNumber / 10;
}
}
这段代码的执行流程用一个小例子走一遍就能完全理解。
输入 123321（偶数位回文）：
- 前置判断：不是负数，末位不是 0，通过
revertedNumber = 0，x = 123321- 循环第 1 次：
revertedNumber = 1，x = 12332 - 循环第 2 次：
revertedNumber = 12，x = 1233 - 循环第 3 次：
revertedNumber = 123，x = 123 - 循环终止（
x == revertedNumber） x == revertedNumber成立，返回true
输入 12321（奇数位回文）：
- 前置判断通过
- 循环第 1 次：
revertedNumber = 1，x = 1232 - 循环第 2 次：
revertedNumber = 12，x = 123 - 循环第 3 次：
revertedNumber = 123，x = 12 - 循环终止（
x < revertedNumber） x == revertedNumber / 10（12 == 12）成立，返回true
4.2 Python 实现
Python 里没有整型溢出问题，所以直接用完整反转在功能上不会出错，但半反转法依然有学习和借鉴价值，尤其是在面试中展示你对"计算效率"和"边界条件"的敏感度：
python复制def is_palindrome(x: int) -> bool:
if x < 0 or (x % 10 == 0 and x != 0):
return False
reverted_number = 0
while x > reverted_number:
reverted_number = reverted_number * 10 + x % 10
x //= 10
return x == reverted_number or x == reverted_number // 10
需要注意的是 Python 的整数除法用 //，而在 Java/C++ 里直接是 /，因为整数类型相除自动截断。这个语法差异在写代码的时候要格外注意，稍不留神就会写出浮点结果，导致逻辑错误。
4.3 C++ 实现
cpp复制class Solution {
public:
bool isPalindrome(int x) {
if (x < 0 || (x % 10 == 0 && x != 0)) {
return false;
}
int revertedNumber = 0;
while (x > revertedNumber) {
revertedNumber = revertedNumber * 10 + x % 10;
x /= 10;
}
return x == revertedNumber || x == revertedNumber / 10;
}
};
C++ 的写法和 Java 几乎一致，这就是这个算法的优点：不依赖任何语言特性，只用了基本的整数运算和循环，迁移成本极低。
4.4 代码的可读性权衡
很多人写完代码后会纠结：要不要把"是否回文"这个判断抽成独立函数？我的建议是，面试或刷题场景下保持上面的写法就很好，因为三个逻辑块（前置判断、半反转循环、最终判断）各自职责非常清晰，代码量少又不需要额外注释来解释流程。
如果在工程项目里，建议封装成工具方法，并且在方法注释里写清楚"为什么用半反转而不是完整反转"——这个原因就是避免整型溢出。工程代码的注释重点不是解释语法，而是解释"为什么不那么写"，后来的维护者才不会误改。
5. 复杂度分析与相关场景延伸
5.1 时间复杂度为什么是 O(log n)
回文数判断的时间复杂度分析，很多资料都直接给结论"O(log n)"，但没有讲清楚这个 n 到底是什么。
这里的 n 是输入整数的大小，而循环次数取决于这个整数的十进制位数。一个数字的十进制位数是 log10(n) 级别。比如 n = 1000，位数是 4，约等于 log10(1000) + 1。半反转法循环的次数是位数的一半，所以时间复杂度是 O(log n) 级别。更严谨地说，应该是 O(log10(n))，但大 O 表示法省略底数，统一记为 O(log n)。
对比直接反转法，直接反转整个整数需要循环完整位数，而半反转法只需要一半位数。虽然在大 O 级别上两者都是 O(log n)，但实际循环次数差了约一倍，对于 10 位数字的输入，直接反转要循环 10 次，半反转只循环 5 次。这个性能差异在高频调用的场景下是可以感受到的。
5.2 空间复杂度：O(1) 的关键意义
半反转法只使用了两个整型变量（revertedNumber 和 x），不依赖额外数组、字符串或栈结构。空间复杂度是 O(1)，这是它优于"转换成字符串再判断"的地方。
有些人可能会问：LeetCode 上很多人用字符串反转，代码不是更短吗？比如 Python 一行：
python复制def is_palindrome(x: int) -> bool:
s = str(x)
return s == s[::-1]
这个写法功能上没错，Python 里字符串反转也不会溢出。但它的空间复杂度是 O(n)，需要为字符串和反转后的字符串申请额外内存。如果面试要求"不使用额外空间"或"不转换为字符串"，直接反转法的变体就失效了，半反转法才是符合要求的解法。这也是面试官更倾向于看到半反转法的核心原因——它用原地修改变量的方式完成了判断，完全不动用额外空间。
5.3 半反转法思路的扩展应用
半反转法提炼出的核心思想是"利用对称性，将完整计算缩减为半量计算"。这个思路在计算机科学里其实很通用，比如：
- 判断链表是否回文：先用快慢指针找到中点，再将后半段链表原地反转，最后逐节点比较。这个过程本质上也是"只处理一半"的典型应用。
- 大整数比较：某些场景下只需要判断一个超大整数的首尾部分是否对称，可以先比较位数，再只取前后若干位进行对比，节省大量运算成本。
- 字符串中心扩展法：最长回文子串的经典解法之一，从中心向两侧扩展，利用的同样是回文结构的对称特性，只不过方向是从内向外，而半反转法是从外向内收敛。
如果在面试中被追问"你还知道哪些类似的思路"，能接出这几个例子，会明显显得比只会背题的人高一个层次。
5.4 常见误区与避坑清单
我在学习这个算法的过程中，总结出四个最容易踩的坑，这里一起列出来：
- 漏掉末尾为 0 的前置判断。这会导致
10被误判为回文数。只要在本地跑一个10的用例，立刻就能发现问题。 - 循环终止条件写反。如果写成
while (revertedNumber < x)和while (x > revertedNumber)，效果一样，但有人会写成while (x >= revertedNumber)，这会导致多循环一次，最终结果出错。正确写法是严格大于，不是大于等于。 - Python 语法里用了
/而不是//。Python 的/是浮点除法，计算x / 10会得到浮点数，后续比较全部失效。 - 忘记处理奇数位数的
revertedNumber / 10判断。经常有人只写了x == revertedNumber，导致12321这类输入返回false。
这四个坑我用一个自检脚本全部测过，只要测试集覆盖了 0、10、11、121、1221、12321、2147447412 这组数据，基本可以确认算法实现没有遗漏。
注意：
2147447412是Integer.MAX_VALUE附近少有的回文数，也是一个很好的测试点，用来验证算法在接近边界情况下不会溢出、结果依然正确。
6. 这类题在真实面试里的考察方式
6.1 面试官期待你主动分析边界
回文数判断按难度划分属于"简单题"，但面试官往往会在你写完代码后追加一系列问题：
- "如果输入是负数怎么办？"
- "如果输入是 10 的倍数怎么办？"
- "如果输入是
Integer.MIN_VALUE呢？" - "你能做到不把整数转成字符串吗？"
- "如果这个函数要调用一百万次，你的实现够快吗？"
这些问题里，前两个属于边界条件，第三个牵涉到最小负数的特殊性质，第四个考察空间复杂度意识，第五个则是对时间复杂度的追问。很少有候选人能在不提前准备的情况下完整答出所有问题，尤其是"末尾为 0"这个前置条件，几乎一半以上的人第一次写都会漏掉。
我的建议是，面试时不要急着写代码，先把边界情况口头分析一遍再动手。这个"先说后写"的习惯会让面试官觉得你是一个考虑周全的工程师，而不是一个只会套模板的刷题机器。
6.2 与同样使用双指针的思路对比
回文数判断还有一种思路：把数字转成数组或字符串后用双指针从两端向中间移动，逐位比较。这个思路的优点是直观、好写，缺点和字符串反转法一样——需要 O(n) 的额外空间。
面试中如果我先写了双指针版本，面试官通常会说"能不能不用额外空间？"这时候再切换到半反转法，就展示了自己的思维灵活性。反过来，如果一开始就写半反转法，面试官可能会问"半反转法和双指针法各自的优劣是什么"，这就更进一层的考察了。
两种思路的本质区别在于：
- 双指针法是"从两端向中间读取"，读取的是原始数据的同一个副本。
- 半反转法是"从两端向中间构建"，一侧保留原值，一侧构建反转值，最终在中点汇合。
同一个问题，两种思维路径，最后落在代码上却有显著的空间复杂度差异。这就是算法题的魅力所在。
6.3 关于学习方法的个人体会
半反转法这个知识点，单看代码就那么几行，但真正把它吃透需要理解三层：第一层是"如何实现"，第二层是"为什么要半反转"，第三层是"半反转的边界在哪里"。大多数人停留在第一层，背下来就过；但如果你愿意花点时间把第二层和第三层想清楚，这类题基本就再也不会难住你了。
我个人的学习建议是：
- 拿到一道题，先不看题解，自己写一版解法，哪怕是最笨的字符串反转也行。
- 然后 deliberately 地找一个反例，比如那种会让你的解法出错的输入，比如 10 或
2147483647。 - 主动分析解法的时间复杂度和空间复杂度，找出瓶颈。
- 最后再去参考优秀题解，对比差异并总结成自己的笔记。
这套流程看起来慢，但对算法思维的训练效果远高于直接反复刷题。回文数判断是一个小切口，但通过这个小切口掌握"对称性"这个底层思路，后续遇到很多相关题目都会豁然开朗。
另外，实际写代码的时候，建议把测试数据覆盖得全面一些，不要只测 121 这种一眼就能看出来的例子。多用边界值去测，比如 0、10、100、1001、10001、9999、2147447412，遇到问题立刻就能暴露。我和同事交流过，大家普遍认可一点：这类简单题其实最考验基本功，因为一个边界条件漏掉，整道题的答案就是错的，没有任何模糊空间。
如果你现在正在准备面试或者刚学算法没多久，我建议把回文数判断这个题目作为"边界条件分析"的典型例题来练，不要只背半反转法这一种写法，而是把它背后的"为什么"彻底弄明白。弄明白之后，你会发现自己看其他题目时，自然会开始关注边界、关注空间复杂度、关注是否存在更优解，这些意识才是真正有价值的东西。