JavaScript 中数组的创建方式，看似只是语法细节，但实际上直接影响代码的语义清晰度、行为一致性以及团队协作的流畅性。选对了，代码干净高效；选错了，可能埋下难以定位的隐性 Bug，增加排查难度。首先给出核心判断：从代码可维护性的角度看，字面量几乎始终是最优选择，但如果能善用 ES6 提供的静态方法，团队编码体验还能进一步提升。
下面具体分析不同创建方式带来的实际影响。
字面量方式：安全直观，对引擎友好
使用 const arr = [1, 'a', true] 这样的字面量语法来创建数组，是绝大多数场景下的首选方案。语法直观清晰，没有歧义，JavaScript 引擎对其优化也最为充分。所有主流代码检查工具（如 ESLint）都将其列为默认推荐。团队成员一眼就能看出这是一个“带真实内容的数组”，无需担心它是占位符或未初始化的空数组。
但现实中仍有一些常见误用：
- 试图创建 [5]，却误用 new Array(5)，结果生成了一个长度为 5 的空槽数组。后续使用
map或forEach时，循环可能无法执行，这类 Bug 在分支逻辑中尤为隐蔽。 - 动态拼接参数时，硬编码
new Array(...args)不如改用展开语法[...args]。后者语义更清晰，兼容性也更好，几乎没有理由继续使用前者。
构造函数：特定场景下合理使用
new Array() 和 new Array(n) 并非错误，但不能滥用。应严格限定在意图明确的场景下：
- 当确实需要预分配固定长度的数组（如用于 canvas 像素缓冲区）且后续逐项赋值时，
new Array(1024)比Array(1024).fill(null)更轻量，可以接受。 - 从后端接口获取一个纯数字长度值，需要初始化空数组用于后续填充，配合注释说明用途也是合理的。
- 但需警惕：绝对不要在条件分支或参数不确定时使用单参数构造函数，风险远大于收益。一旦变量处于边界值或混合类型，很容易出现问题。
ES6 静态方法：声明式表达意图
Array.from() 和 Array.of() 的出现，在很大程度上弥补了构造函数的历史缺陷，同时提升了代码的声明性。其价值不可忽视：
Array.from({length: 5}, (_, i) => i * 2)清晰表达了“生成一个包含 5 个偶数的数组”，无需手动循环push，可读性和可维护性显著提升。Array.of(3)始终返回 [3]，彻底解决了new Array(3)的歧义。如果团队需要封装工具函数处理数字参数的数组初始化，Array.of是首选。- 处理 DOM 的 NodeList、Set、Map 等类数组结构时，
Array.from(nodeList)比Array.prototype.slice.call(nodeList)更易理解，兼容性也无须担心，实用价值很高。
统一规范：项目可维护性的基石
归根结底，影响项目长期可维护性的关键并非“能否使用某种方式”，而是“全项目是否保持一致性”。今天有人用字面量，明天有人写 new Array(3)，后天又出现 Array.of 组合，久而久之代码会像拼图一样难以统一维护。建议在团队代码规范中明确以下底线：
- 默认优先使用字面量，禁止无注释的
new Array(x)。 - 涉及类数组转换或需要预设映射时，优先使用
Array.from；需要兜底时统一使用Array.of。 - 禁止
new Array配合变量解构（如new Array(...data)），统一替换为展开语法。 - 在 CI 流程中添加 ESLint 规则（如
no-array-constructor），自动拦截高风险写法，避免依赖 code review 逐一纠正。
代码规范并非技术细节，而是团队协作的基石。统一之后，团队无需再猜测彼此的写法。
