首页 / 文章 / 避免因 JavaScript 引用变异导致的静默状态错误

JavaScriptReactImmutabilityState ManagementPerformance

避免因 JavaScript 引用变异导致的静默状态错误

了解为何通过引用修改对象和数组会破坏 React 的重新渲染机制，为何展开运算符仅能实现浅层复制，以及如何安全地对状态进行深度克隆。

1565 词

用户在你们的SaaS产品中打开账户设置弹窗，将工作空间名称从“Acme Marketing”改为“Acme Global”，随后又改变主意并点击了取消。

弹窗消失了，但顶部导航栏中的工作空间名称也变成了“Acme Global”。

用户困惑地重新加载页面，名称又变回了“Acme Marketing”。

经过深入排查后发现，表单的状态存储在本地组件状态中，点击取消并未触发任何网络请求。那么，为何从未保存的修改会影响到全局标题呢？

罪魁祸首是两行看似简单的代码：

// In the modal component
const formState = currentUser.workspace;
formState.name = newName; // Direct object reference mutation!

这是JavaScript应用中一种常见且容易被忽视的故障模式：通过共享引用导致的意外修改。

由于 JavaScript 中的对象和数组是通过引用而非值来处理的，因此在一个组件中修改某个对象可能会悄无声息地改变应用中其他地方使用的相同底层数据——这会绕过状态管理机制，打乱 React 决定何时重新渲染的逻辑，最终让你面对一个没有明显原因的错误。

1. 引用相等性：JavaScript 如何看待你的数据

要理解为何修改数据会引发如此多的问题，首先需要了解 JavaScript 引擎实际上是如何在内存中存储这些值的。

原始值——数字、字符串、布尔值、null、undefined——是通过值来复制的：

let a = 10;
let b = a;

b = 20;console.log(a); // 10 (unchanged)

对象、数组和函数的工作方式不同：它们是通过引用存储的。存储对象的变量并不直接包含对象的数据——它只保存指向该数据实际所在内存位置的指针：

const userA = {
  name: "Sarah",
  role: "Admin"
};

const userB = userA; // userB points to the EXACT same memory address!userB.name = "Alex";console.log(userA.name); // "Alex" — userA was mutated!

像 React 这样的现代 UI 框架大量依赖浅层相等性检查（使用 Object.is 或 ===）来判断组件是否真的需要重新渲染。

因此，如果你直接修改了现有对象后再将其传给 setState：

// BAD: Mutating existing state directly
const [user, setUser] = useState({
  name: "Sarah",
  age: 30
});

function updateAge() {
  user.age = 31; // Direct mutation
  setUser(user); // Passes the SAME memory reference!
}

React 会将之前的状态引用与新的引用进行比较。由于它们在内存中实际上是同一个对象，React 会判定没有发生变化，从而完全跳过重新渲染步骤。

底层数据已经更新，但界面仍停留在旧状态。

2. 展开运算符的误区

为避免直接修改数据，许多开发者会使用对象的展开运算符（...）。这确实是个实用的工具，但人们常误以为它能够生成完整的深度复制。

事实并非如此。

展开运算符仅复制对象的顶层结构。其中嵌套的任何对象或数组仍与原对象共享引用。

以常见SaaS应用中的设置对象为例：

const defaultSettings = {
  theme: "dark",
  notifications: {
    email: true,
    sms: false
  }
};

// Shallow copy using spread
const userSettings = { ...defaultSettings };// Changing a nested property
userSettings.notifications.email = false;// Disaster: defaultSettings was also mutated!
console.log(defaultSettings.notifications.email); // false!

由于notifications本身也是一个对象，因此userSettings.notifications和defaultSettings.notifications仍然指向同一块内存。

如果 defaultSettings 是一个共享的模块级常量，那么修改某位用户的偏好设置就可能会悄悄破坏应用程序其他地方使用的默认配置。

3. 数组方法的隐患

JavaScript 提供了若干内置的数组方法，这些方法会修改被调用的数组本身，而非返回一个新的数组。

如果将来自 props 或共享状态的数组传递给这些方法，就会产生意想不到的副作用：

// METHODS THAT MUTATE IN PLACE (Dangerous with state)

array.sort();     // Mutates original array!
array.reverse();  // Mutates original array!
array.splice();   // Mutates original array!
array.push();     // Mutates original array!
array.pop();      // Mutates original array!

想象一个用于渲染交易列表的表格组件：

// BAD: Direct prop mutation during render
function TransactionTable({
  transactions
}: {
  transactions: Transaction[];
}) {
  // transactions.sort() permanently reorders the array in parent state!
  const sorted = transactions.sort(
    (a, b) => b.amount - a.amount
  );

  return (
    <table>
      {sorted.map((tx) => (
        <tr key={tx.id}>
          <td>{tx.amount}</td>
        </tr>
      ))}
    </table>
  );
}

每次渲染 TransactionTable 时，都会悄悄改变实际上属于父组件的交易数组顺序。

现代解决方案：不可变数组方法

最新版本的 ECMAScript 引入了这些方法的不可变版本，它们都会返回一个新的数组而不会修改原数组：

可变方法（应避免）与其不可变替代方案（推荐使用）：arr.sort(fn) 变为 arr.toSorted(fn)，arr.reverse() 变为 arr.toReversed()，arr.splice(start, count) 变为 arr.toSpliced(start, count)，而 arr[index] = val 则变为 arr.with(index, val)。

无需直接修改 transactions 数组：

// GOOD: Leaves the original transactions array pristine

const sorted = transactions.toSorted(
  (a, b) => b.amount - a.amount
);

4. 现代深度复制：structuredClone 与 JSON 方法

当您的应用程序确实需要嵌套状态的深度、完全独立的副本时，就该摒弃旧的 JSON.parse(JSON.stringify(obj)) 临时解决方案了。

那种基于 JSON 的方法存在几个严重的缺陷：

  • 函数和 undefined 值会被悄悄忽略。
  • 日期对象会变成普通的 ISO 字符串，而不会保持为 Date 实例。
  • Map、Set、RegExp 和 ArrayBuffer 对象也会在处理过程中被销毁。
  • 循环引用会导致程序直接抛出错误。

标准方案：structuredClone()

目前所有的浏览器和 Node.js 运行时都原生支持 structuredClone()：

const originalProject = {
  id: "proj_123",
  metadata: {
    createdAt: new Date(),
    tags: new Set(["frontend", "ui"])
  },
  collaborators: [
    { name: "Sarah" }
  ]
};

// Creates a complete, true deep copy
const clonedProject = structuredClone(originalProject);clonedProject.metadata.tags.add("react");
clonedProject.collaborators[0].name = "Alex";// Original remains completely untouched
console.log(
  originalProject.metadata.tags.has("react")
); // falseconsole.log(
  originalProject.collaborators[0].name
); // "Sarah"console.log(
  originalProject.metadata.createdAt instanceof Date
); // true

对 originalProject 调用 structuredClone 可以生成一个真正独立的副本：因为所有嵌套结构都是被复制而非仅被引用，所以修改副本中的标签集或更新嵌套协作者的姓名都不会对源对象产生任何影响。

5. 当不可变性成为性能问题时

不可变性能让 UI 逻辑更具可预测性，但如果不加注意，在每次更新时都进行深度克隆可能会影响性能。

想象一下包含 50,000 行数据的数据网格，或是以画布为基础的图表每秒运行 60 次计算。每次交互时都通过 structuredClone 或其他方式对整个结构进行深度克隆，会生成大量垃圾数据需要垃圾回收器处理，浏览器在反复分配和释放大块内存时就会出现卡顿现象。

平衡之道

  1. 仅对需要修改的层级进行浅层复制：如果更新仅涉及 user.name，只需对顶层数据进行浅层复制即可：
{ ...user, name: "New Name" }
  1. 当嵌套层级很深时，应使用结构共享库：对于具有多层结构的状态树，像 Immer 这样的工具可以帮助你避免进行完整的深度复制。Immer 利用 JavaScript Proxy 对象仅克隆实际被修改的节点，因此未被修改的节点仍会指向其原始引用。
import { produce } from "immer";

// Clean, intuitive mutation syntax with zero reference pollution
const nextState = produce(currentState, (draft) => {
  draft.users[0].preferences.theme = "dark";
});

这种方式能让你使用类似修改操作的简洁语法，同时 Immer 会在后台自动生成一个新的、已正确更新的状态对象，从而避免意外的引用共享问题。

总结与不可变性规则

为避免 JavaScript 代码库中出现隐蔽错误和状态异常：

  1. 不要直接修改属性或状态：将所有来自外部作用域的数据视为只读数据。
  • 请记住浅拷贝的局限性： { ...obj } 和 [ ...arr ] 只会复制最顶层的内容；嵌套的对象和数组仍然共享同一个引用。
  • 优先使用 to... 系列数组方法： 应选用 toSorted()、toReversed() 和 toSpliced()，而非会修改原数据的 sort() 等方法。
  • 需要真正深度拷贝时使用 structuredClone： 在处理复杂的嵌套数据时，不要再依赖 JSON.parse(JSON.stringify()) 了。
  • 充分利用结构共享机制： 对于深度嵌套的状态，Immer 能让你在不进行全量拷贝的情况下高效更新数据。

    • 遵守引用相等性原则并严格遵循不可变性的要求，能够避免一大类生产环境中的错误——这类错误否则会耗费数小时进行令人困惑的调试。

    相关阅读

  • 浏览器如何绘制页面以及React在其中的作用 — 了解关键渲染路径、状态同步机制、Fiber架构以及调度器是如何协同工作，将React的更新转化为屏幕上的像素的。
  • 前端性能：从代码审查的盲点到产品指标 — 了解为何仅通过代码审查是不够的，哪些核心Web指标真正重要，以及如何衡量和解决实际中的React性能问题。
    • 全部文章发送简报