React状态更新中安全使用Array.prototype.toSorted方法

在React开发中，状态更新的“不可变性”原则是老生常谈，但一个不起眼的数组排序操作就可能让你踩坑。ES2024标准正式引入了Array.prototype.toSorted()方法，它可以说是为React的不可变更新量身定做的。与传统的sort()相比，它从设计源头就杜绝了副作用，让状态管理变得更安全、更优雅。

toSorted与sort的区别：为何toSorted更安全

问题的核心在于“就地修改”与“返回新值”的区别。React推崇不可变数据，要求每次状态更新都返回一个全新的引用。传统的arr.sort()直接在原数组上进行排序，也就是“就地排序”。

这会导致什么后果？假设你对一个状态数组调用了sort()，然后将其设置回状态。由于数组的引用地址没变，React的浅比较机制可能误判“状态未更新”，从而跳过必要的重新渲染。更棘手的是，如果这个数组还被其他useEffect钩子所依赖，这种隐性的修改会引发难以追踪的竞态问题和状态残留Bug。

而toSorted()则完美避开了这些雷区。它永远返回一个全新的、排序后的数组副本，原数组保持不变。这意味着每次调用，引用必然变化，从而确保React能可靠地触发组件更新和依赖项的重新计算。

在React useState中正确使用toSorted方法

使用起来非常直观。你可以在状态更新函数中直接调用toSorted()，无需任何中间变量或额外的展开操作，代码既简洁又安全。

const [items, setItems] = useState([{ id: 2, name: 'Beta' }, { id: 1, name: 'Alpha' }]);

//  安全：生成新数组，引用变化
setItems(prev => prev.toSorted((a, b) => a.id - b.id));

//  危险：修改原数组，且 set 的仍是原引用
setItems(prev => {
  prev.sort((a, b) => a.id - b.id);
  return prev; // 错误！prev 已被污染
});

上面这个反面例子是个经典陷阱：sort()已经污染了原数组，即使你把它返回给setItems，传入的也已经是同一个被修改过的引用，违背了不可变原则。

配合其他不可变操作链式使用toSorted

toSorted()的魅力在于它能无缝融入现有的函数式编程链条。你可以将它和filter、map等纯方法组合使用，构建出一个完全无副作用的更新流水线。

• 先过滤，再排序：setItems(prev => prev.filter(x => x.active).toSorted((a, b) => b.score - a.score))
• 排序后，再映射（比如添加排名序号）：setItems(prev => prev.toSorted((a, b) => a.name.localeCompare(b.name)).map((item, i) => ({ ...item, rank: i + 1 })))

这里的关键是，整个链条中的每一步都必须返回一个新数组。务必警惕在链式调用中混入.push()、.splice()或直接赋值这类具有破坏性的操作。

toSorted的浏览器兼容性与降级方案

当然，拥抱新特性的同时也要考虑现实。目前，toSorted()已在Chrome 117+、Firefox 119+、Safari 17.4+等现代浏览器中原生支持。对于生产环境，通常有两条路：

• 首选方案：通过构建工具Polyfill。使用Babel并配置@babel/preset-env时，开启shippedProposals: true选项，它可以自动为尚未正式纳入标准但已稳定的提案（如toSorted）注入对应的polyfill。
• 手动降级方案：如果项目环境无法引入polyfill，可以采用传统的“展开+排序”模式：[...prev].sort(...)。展开运算符会先创建一份数组副本，再对副本进行排序，语义上与toSorted()等价，只是多了一次浅拷贝。相比之下，Array.from(prev).sort(...)虽然也安全，但性能通常略逊于展开语法。

随着ES2024标准被广泛支持，未来我们可以更放心地直接使用toSorted()，让代码意图更加清晰，也让React的状态更新变得更加稳健。