递归结束的判断条件写==和>=有区别吗

... 更严格的条件有利于发现潜在的问题
更宽松的条件有利于养肥潜在的问题

楼主真要“缜密”的话就把 > k 的情况给 assert/unreachable 掉

如果歩长从 1 变成 2 了怎么办？

还真别说，宇宙粒子导致位元反转不少见

== 的话，没问题，>= 容错率更高，但容错意味着隐藏 Bug，所以在写代码特时候，用 >= 的时候也要思考，即使不正常地出现了 > 的情况，会不会对后续程序造成影响，如果会造成影响，一定要抛个异常。

世界线变动了

其实不考虑容错率，可以从另一个场景看来这个问题：

A 的年龄是 B 的两倍加上 C 的年龄后再减去 B 的年龄，求 A 的年龄：

a = 2b + c - b;

这个代码的效果其实跟下面的是等价的：

a = b + c;

二者都没有错，但我更偏向于在代码中保留第一种写法，也就是更符合「直觉」、更有「含义」的写法。

当然，这是个很简单的例子，所以你可能觉得很弱智。但碰到复杂的公式计算，我通常也都不会尽自己可能地去化简到极致来减少计算机的运算，而是保留符合直觉且有含义的写法，哪怕更复杂。

回到你的例子。我在写迭代的时候，遇到 base case，也会根据题意去定义条件。比如，如果题目说「当超过 xx 时便不再……」，那么我就会把条件写成 >= 或者 <=；而如果题目说「直到它为 xx 时便不再」，那么我就会写成 == 或者 !=。

再说回上面大家提到的容错率。如果你的代码真的符合题意背景，且它可以被证明是能达到 == 的条件的（请注意这个前提），便无需焦虑于使用一个 >= 来加以保护，甚至这么做会破坏了我刚刚所说的直觉和含义。如果你真的需要这一层防护的话，那么就是你写错了，请直接 debug，而不是靠这一层神秘防护来「修复」 bug 。

当然……（老胡认为？）凡事没有一定，上面有很多建议是从工业代码、防备猪队友的角度出发，楼主如果已经处于工业代码的屎山中，完全无法做到缜密地顾全一切，那就大势所趋吧。