moment.js为何要设计成mutable的，有何优缺点？

剖析 moment.js 的“可变性”设计：优劣并存的取舍

moment.js，这款曾经席卷前端界的日期时间处理库，其核心设计之一——可变性（mutability）——一直是一个备受讨论的话题。为何它要选择这样一条“不那么纯粹”的道路？这种设计又带来了哪些得失？让我们深入剖析。

什么是“可变性”？

首先，我们需要明确“可变性”在 moment.js 中的含义。简单来说，当一个 moment 对象是可变的，意味着你对它进行任何操作（如 `.add()`, `.subtract()`, `.startOf()`, `.endOf()` 等）时，原始的 moment 对象本身会被修改，而不会返回一个新的 moment 对象。

举个例子：

```javascript
let date = moment('20231027');
let newDate = date.add(1, 'day');

console.log(date.format()); // 输出：20231028T00:00:00+08:00
console.log(newDate.format()); // 输出：20231028T00:00:00+08:00
```

在这个例子中，`date.add(1, 'day')` 直接修改了 `date` 对象本身，`newDate` 指向的也是同一个被修改后的对象。

为何选择“可变性”？历史背景与设计考量

moment.js 在设计之初，主要有以下几个原因驱动了其对可变性的选择：

1. 性能考量与内存优化： 在JavaScript生态早期，内存管理和性能是开发者非常关注的问题。如果每一次对日期进行增减、格式化等操作都需要创建一个全新的对象，那么在频繁的日期计算场景下，会产生大量的临时对象，增加垃圾回收的压力，降低程序的运行效率。可变性设计可以通过复用现有对象来减少不必要的内存分配和对象创建，从而在一定程度上提升性能。

2. API 的简洁性与直观性： 可变性的 API 设计，使得操作更加“原地”和直接。例如，`date.add(1, 'day')` 就像是直接在 `date` 这个“容器”里增加了时间，而不是“生成一个新的、比原来晚一天的时间”。这种方式在某些场景下，尤其是对于那些习惯了命令式编程风格的开发者来说，可能更加直观易懂，降低了学习成本。

3. 兼容早期 JavaScript 模式： 在 JavaScript 逐渐成熟的过程中，许多库和框架的API设计都倾向于直接修改对象状态。moment.js 的可变性设计也契合了当时一些主流的编程范式，使得它能够更容易地融入现有的代码库。

4. 模拟真实世界的“时间流逝”： 日期和时间在我们的认知中，是不断向前流逝的。可变性在某种程度上也模拟了这种“改变”的过程，一个日期对象“经过”一段时间后，它自身就变成了新的日期。

优点：便捷与效率的背后

尽管“可变性”在现代编程范式中常被诟病，但在 moment.js 的时代，它确实带来了不少优势：

API 链式调用更流畅： 可变性使得连续的操作更加自然。例如：
```javascript
let date = moment('20231027');
date.add(1, 'day').subtract(2, 'hours').startOf('hour');
// 这里的 date 对象在每一步都被修改了
```
如果每次操作都返回新对象，那么链式调用虽然也可以实现，但内部会涉及更多的对象创建和赋值。

减少不必要的对象创建： 如前所述，在大量计算时，避免了重复创建对象，节省了内存和CPU资源。这在资源相对有限的早期前端环境中尤为重要。

易于理解的“状态更新”： 在一些简单的场景下，开发者只需要关注一个日期变量的状态变化，可变性提供了一种直接的更新方式，无需关心新旧对象的交替。

缺点：陷阱与隐患的根源

然而，可变性设计也为 moment.js 埋下了不少“坑”，这些缺点是导致其在现代JavaScript社区中逐渐被取代的重要原因：

难以预测的副作用（Unintended Side Effects）： 这是可变性最核心的缺点。当你在代码中传递一个 moment 对象作为参数，或者在多个地方引用同一个 moment 对象时，一旦其中一个地方对该对象进行了修改，所有引用它的地方都会受到影响，即使它们并不希望如此。这会导致代码逻辑变得难以追踪和调试。

```javascript
function processDate(date) {
date.add(7, 'days'); // 修改了原始传入的 date
return date.format('YYYYMMDD');
}

let myDate = moment('20231027');
let processedString = processDate(myDate);

console.log(myDate.format('YYYYMMDD')); // 输出：20231103，myDate 被意外修改了
```
这种行为违背了“函数式编程”中“纯粹性”的原则，即一个函数不应该产生外部可见的副作用。

可测试性降低： 由于可变性容易引入难以控制的副作用，使得单元测试变得更加困难。在测试一个依赖于 moment 对象修改的函数时，需要仔细管理和重置 moment 对象的状态，增加了测试的复杂性。

并发场景下的问题： 在多线程或异步操作频繁的环境中，如果多个异步任务共享同一个可变 moment 对象，并同时对其进行修改，很容易导致数据竞争和不可预期的结果。

与现代 JavaScript 范式不符： 随着 React、Vue 等声明式 UI 框架的兴起，不可变性（immutability）成为了主流的编程理念。通过不可变性，可以更容易地进行状态管理、变化检测，并减少副作用。moment.js 的可变性与之相悖，使得它在现代前端开发中显得格格不入。

在函数参数和返回值传递时需要格外小心： 为了规避可变性带来的问题，开发者必须时刻警惕，在传递 moment 对象给其他函数时，务必先进行克隆（`.clone()`），或者在使用完毕后将其重置。这无疑增加了开发者的心智负担。

总结：一个时代的产物

moment.js 的可变性设计，是特定历史时期技术发展和工程考量的产物。它在一定程度上解决了当时的性能和 API 设计挑战，使得日期处理变得更加便捷。

然而，随着 JavaScript 生态的成熟和编程范式的演进，可变性所带来的副作用、调试难度以及与现代开发理念的冲突，逐渐暴露了其不足。这最终导致了像 `datefns` 和 Day.js 这样遵循不可变性原则的库的兴起，并在现代前端开发中占据了主导地位。

可以说，moment.js 的可变性设计，就像是那个年代下的一种“权宜之计”，在带来便利的同时，也埋下了隐患。理解其设计思路，有助于我们更深刻地认识不同编程范式之间的差异，以及技术选择背后的权衡与取舍。如今，虽然 moment.js 的维护已进入“只读”模式，但它留下的经验和教训，依然值得我们学习和借鉴。

2022 年来看这个老问题，答案已经不重要，因为连 moment.js 官网都建议你别在新项目上引入 moment.js，因为原生 API 已经能做很多原本需要 moment.js 的事情。