new Array传入数值20时生成长度为1的数组，硬编码同值则行为正常

new Array()构造函数的双模式执行逻辑，是这类问题的核心来源：

• 当传入单个原始number类型参数时：构造函数会创建长度等于该数值的稀疏空位数组，数组本身不存在可遍历的实际元素索引。map/forEach/filter等原生数组遍历方法默认会跳过数组中的空槽，直接对这类数组执行map本来就无法得到填充后的结果——如果硬编码new Array(20)时能正常返回20个元素，说明你的运行环境对稀疏数组的遍历逻辑做了兼容。
• 当传入单个非number类型参数时：不管这个参数的视觉表现是不是数字（比如字符串形式的"20"、Number包装对象、被意外类型转换的值），构造函数都会直接把该参数作为数组的第一个初始元素，返回长度为1的数组，和你遇到的“最终结果长度恒为1”的现象完全吻合。

你观察到的“硬编码就正常、传参就异常”的差异，本质上说明传参场景下的total根本不是原始number类型——哪怕控制台打印出来的值是20，也可能是被类型转换后的“假值”。

• 校验入参真实类型：在函数入口添加日志console.log(typeof total, Object.prototype.toString.call(total))，确认total是原始number类型，而非字符串、包装对象等非原始数值类型。很多场景下从接口、表单、配置文件取到的“数字”实际是字符串，控制台打印的视觉效果和原始数字完全一致，但会触发Array构造函数的单元素返回分支。
• 排查全局原型篡改：检查代码全局是否存在自定义覆写Array构造函数、Array.prototype.map的逻辑，部分第三方库会修改原生数组方法的执行规则，导致传参场景和硬编码场景的行为不一致。
• 核对入参传递链路：追踪调用addressGenerator的代码逻辑，确认是否存在变量引用错误，把其他类型的值误传给了total参数。

放弃new Array(total).map()的稀疏数组写法，这类写法的原生兼容性不稳定，可替换为以下逻辑：

• 使用Array.from({ length: total }, () => f())：显式创建指定长度的数组，每个索引都会实际赋值，不存在空槽，遍历行为完全稳定。
• 使用new Array(total).fill(null).map(() => f())：先通过fill方法把稀疏数组填充为实际存在的元素，避免空槽被遍历方法跳过。
• 简单循环实现：初始化空数组后按total次数执行push操作，逻辑直观，完全规避构造函数的分支陷阱。

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