嘿，这个问题其实很有意思——你看到的性能差异根本不是「嵌套循环vs函数调用」的锅，核心是两者的质数判断逻辑效率天差地别！

先拆解你的函数版代码：isPrime方法里的内层循环是for(int i=2;i<=Math.sqrt(n);i++)，这是质数判断的经典优化：如果一个数n有大于√n的因数，那必然对应一个小于√n的因数，所以只需要循环到√n就足够判断是否为质数了，循环次数大幅减少。

而你提到的“嵌套循环实现”，我猜你写的是最常见的未优化版本，大概是这样：

public class Main {
    public static void main(String[] args) {
        int n; boolean flag;
        Scanner input = new Scanner(System.in);
        n=input.nextInt();
        long st=System.nanoTime();
        for(int i=2;i<n;i++) {
            boolean isPrime = true;
            // 这里内层循环是到i-1，而不是√i！
            for(int j=2;j<i;j++) {
                if(i%j==0) {
                    isPrime = false;
                    break;
                }
            }
            if(isPrime) {
                System.out.printf("%d ",i);
            }
        }
        long et = System.nanoTime();
        System.out.println();
        System.out.printf("%.4f",(et-st)/1000000000.0);
    }
}

这两者的循环次数差距有多夸张？拿n=1000举例：

• 函数版判断i=997（1000以内的最大质数）时，内层循环只需要执行到√997≈31，也就是30次左右；
• 而嵌套版判断同一个i=997时，内层循环要从2跑到996，足足995次！单个数字的循环次数差了30多倍，整体运行时间差几十倍完全合理。

另外补充两个细节打消你的顾虑：

• 你可能担心函数调用会有额外开销，但JVM的**即时编译器（JIT）**会把isPrime这种小函数直接内联到调用处，相当于没有函数调用的额外开销，和直接写优化后的嵌套逻辑速度完全一致；
• 如果你的嵌套版还没提前缓存√i的结果（比如每次循环都计算一次平方根），那还会多一层不必要的计算开销，但这只是次要因素。

最后总结：不是嵌套循环本身慢，是你写的嵌套循环用了未优化的判断逻辑（内层循环范围过大），而函数版用了高效的质数判断算法，才导致了这么大的性能差距。

内容的提问来源于stack exchange，提问作者karthik reddy