判断质数只需循环到√n而非n/2，因最小非平凡因子必≤√n；超过后仅为此前因子对的镜像，n/2会多迭代近一倍，大数时显著拖慢；实操用(int)Math.sqrt(n)作上限，或用i*i≤n避免浮点误差。
判断质数时为什么不能只循环到 n/2
因为质数的最小非平凡因子一定 ≤ √n。比如 100 的因子对是 (2,50)、(4,25)、(5,20)、(10,10)，一旦超过 √100=10，就只是前面的镜像。循环到 n/2 会多跑近一倍无意义的迭代，尤其对大数（如 10⁶ 级）明显拖慢。
实操建议：
- 循环上限统一用
(int) Math.sqrt(n)，注意强制转int避免浮点误差 - 别写
i * i —— 虽然数学等价，但对超大 <code>n（接近Integer.MAX_VALUE）可能溢出，i 更安全 - 单独处理
n == 2和n ：小于 2 的数（0、1、负数）都不是质数；2 是唯一偶质数
isPrime(int n) 函数里最容易错的边界情况
很多人写完逻辑，一测就翻车：输入 0、1、2、4 或负数时返回错误结果。这不是算法问题，是没厘清定义。
质数定义是「大于 1 的自然数，且只有 1 和它本身两个正因数」——所以：
立即学习“Java免费学习笔记（深入）”；
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
n 直接返回 <code>false（包括 0、1、负数）-
n == 2返回true（唯一要特判的偶数） -
n % 2 == 0 && n != 2直接返回false（排除其余所有偶数） - 后续循环只需检查奇数因子：
for (int i = 3; i
用 long 型判断大数时的陷阱
如果把函数改成 isPrime(long n)，表面看更通用，但实际埋了两个坑：
-
Math.sqrt(long)返回double，而double对超过 2⁵³ 的整数无法精确表示，会导致开方后向下取整出错（比如Math.sqrt(9007199254740993L)就不准） - 循环变量仍用
int i会溢出——当n接近Long.MAX_VALUE时，sqrt(n)≈ 3×10⁹，超出int范围（2³¹−1 ≈ 2.1×10⁹） - 正确做法：用
long i做循环变量，并改用i * i 判断（虽有乘法开销，但避免了浮点不精确）
性能敏感场景下要不要预筛小质数
如果批量判断多个数（比如 10⁵ 个 ≤ 10⁶ 的数），每次都从头循环开方，不如提前用埃氏筛生成 boolean[] isPrime 查表。但单次判断或数很少时，预筛反而浪费内存和初始化时间。
简单取舍建议：
- 单个数、
n ：直接试除，代码短、无依赖、易维护 - 批量判断、
n集中在某区间（如 [1, 10⁶)）：用埃氏筛预处理，查表O(1) - 数很大（> 10⁹）且量少：考虑 Miller-Rabin 概率算法，但 Java 标准库没内置，需引入第三方或手写，误判率可控但非绝对准确
真正难的不是写对一个 isPrime，而是想清楚你面对的是单次校验、批量预处理，还是高并发低延迟服务里的热路径——选错策略，优化就跑偏了。
