Java求小于N的最大斐波那契数代码边缘测试失败排查

你踩的坑基本都在边界处理和类型选择上，和你猜的一样，确实是对约束和边界场景的覆盖不到位：

• 最小合法输入N=1完全处理错误
  题目明确约束0 < N ≤ 10^9，N=1是合法的最小输入，此时小于1的最大斐波那契数是0，但你的代码跑下来会返回1。
  原因很简单：你初始化first=0, second=1, third=1，当n=1时循环条件third < n就是1<1，直接不成立，返回second=1——这个值等于N，根本不满足“小于N”的要求。
• int类型选型有溢出隐患，临界场景下直接死循环
  Java里int是32位有符号整数，最大值只有2^31-1 = 2147483647（约2.1e9），斐波那契数是指数增长的，第47个斐波那契数就达到2971215073，直接超过int上限，溢出后会变成负数。
  你可能觉得题目N上限是1e9不会触发，但边缘测试本来就会校验代码鲁棒性：一方面你用Math.pow()做浮点数比较本身有精度风险，极端情况下可能放行进超过1e9的输入；另一方面只要N超过1836311903（第46个斐波那契数，1.8e9），计算third时就会溢出得到负数，此时third < n（n是正数）的条件永远成立，直接死循环。就算不考虑超范围输入，面试里用int存指数增长的数值，本身就是没考虑溢出风险的典型扣分项。
• 还有几个不严谨的小问题，虽然不一定直接导致用例失败，但非常容易出问题：
  • 不要用Math.pow()的返回值做整数比较，Math.pow是浮点数运算，大数值下会有精度误差，整数判断直接写字面量就行：比如t<=10000、n<=1000000000，比调用方法靠谱得多。
  • 你写的if(n==0) return 0是死代码，main方法里已经把n<=0的情况全过滤了，这个分支永远走不到。

修复思路 #

1. 补N=1的边界判断，直接返回0；
2. 把存储斐波那契数的first/second/third全改成long类型，彻底避免整数溢出；
3. 把所有Math.pow实现的整数边界判断替换成整数字面量比较。

内容的提问来源于stack exchange，提问作者Ayan Dasgupta