本文揭示了因在模块中使用全局可变数组（如 factors = []）引发的状态污染问题：当 isPrime() 在循环中反复调用时，底层 factorList() 持续向同一数组追加因子，导致质数判断始终失败；核心解法是消除共享状态，改为每次调用都创建并返回独立的局部数组。
本文揭示了因在模块中使用全局可变数组（如 `factors = []`）引发的状态污染问题：当 `isprime()` 在循环中反复调用时，底层 `factorlist()` 持续向同一数组追加因子，导致质数判断始终失败；核心解法是消除共享状态，改为每次调用都创建并返回独立的局部数组。
在实现埃拉托斯特尼筛法（Eratosthenes’ Sieve）时，你可能会依赖一个辅助函数 isPrime() 来判断单个数字是否为质数。但若该函数内部调用了状态不隔离的因数计算模块（如本例中的 factorList.js），程序将在循环中悄然失效——看似逻辑正确，实则输出全为空或全为 false。根本原因并非作用域、异步或导入错误，而是模块级变量的意外共享与累积。
? 问题根源：全局可变数组的“状态污染”
观察原始 factorList.js：
factorList
-
永远避免模块顶层声明可变共享状态（如
let arr = []），尤其当函数被高频调用时； - 函数应尽可能纯：输入确定 → 输出确定，无外部状态依赖或修改；
-
用
const声明局部变量，强制每次调用新建数据结构； -
显式处理边界值：质数定义要求
n ≥ 2，因数枚举应从1起始； - 若需性能优化（如筛法本身），后续可改用布尔数组标记法替代逐个
isPrime判断，但本问题核心在于模块设计原则。
遵循以上重构，你的筛法将稳定输出预期结果，且代码具备可预测性、可测试性与可维护性。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
