React自定义Hook处理数组时映射列表获取上一次渲染旧值问题

两个核心特性是问题的根本来源 #

• Array.prototype.sort() 是原地修改的数组方法：它不会生成新的数组，只会直接在原数组的内存块上调整元素顺序，全程不改变数组的引用地址。
• React的状态更新基于浅引用对比：当你调用setState传入新值时，React只会对比新值和旧值的引用地址是否一致，不会逐元素比对内容/顺序变化。只要引用没变，React就会判定这次状态更新无效，直接跳过重渲染流程。

滞后问题的完整触发链路 #

1. 无搜索内容时，代码走到results = data分支：这里的data是从外部传入的API返回原数组，results直接指向了原数组的内存地址。
2. 后续对results调用.sort()时，本质是直接原地修改了API返回的原数组本身的顺序，整个过程没有创建任何新的数组引用。
3. 当你把这个被修改过的、和原数组同引用的值传给setResult()时，React对比发现传入的引用和上一次存的result state引用完全一致，就会直接跳过这次更新，不会触发组件重渲染。
4. 这就解释了你观察到的诡异现象：控制台打印的数组内容看起来是最新排好序的（因为你确实改了原数组的内存值），但传入子组件的props还是上一次渲染的旧顺序——因为React根本没有触发这次渲染流程，你改的是全局共享的原数组内存，不是React状态需要追踪的新值。

关于控制台输出的疑惑：打印引用类型（数组、对象）时，浏览器控制台是在你展开日志条目时才动态读取内存中的最新值，不会在打印瞬间生成静态快照。哪怕两个数组的内存引用不同，只要内部元素完全一致，打印出来的视觉效果就没有任何区别，但对React的引用检测逻辑来说是完全不同的两个值。

为什么浅拷贝就能修复问题 #

使用results = [...data]时，展开运算符会创建一个全新的数组内存块，哪怕数组内部的元素和原数组完全一样，新数组的引用地址也是独立的。

• 你对这个新数组调用.sort()的时候，修改的是这个独立的拷贝，不会影响原API返回的数组
• 把这个带新引用的数组传给setResult()时，React检测到引用地址和上一次state不一样，就会正常触发重渲染，把最新的排序结果传给子组件。
• 之前搜索功能正常的原因也很好解释：Array.prototype.filter()本身就会返回一个全新的数组引用，所以每次搜索结果传给setState时，React都能正常识别到引用变化，不会出现滞后问题。

通用的修复规范 #

• 所有涉及数组、对象的状态更新操作，永远不要直接修改原数据，永远返回新的引用再传给setState：
  • 排序场景：永远先浅拷贝再排序，比如写const sortedList = [...rawList].sort(排序逻辑)，绝对不要直接对原数组调用.sort()
  • 过滤、映射场景：filter/map本身就返回新数组，不需要额外拷贝
  • 禁止把外部传入的prop、API返回的数组直接作为状态值，除非你明确做了浅拷贝切断引用关联
• 避免在自定义Hook、useEffect的逻辑里直接修改外部传入的参数引用，这类原地修改共享内存的操作很容易引发跨组件的不可预期副作用。

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