盲目堆 React.memo 真的有用吗？聊聊商城重构时的性能翻车现场
你们有没有遇到过这种场景：项目代码量一上来，原本顺滑的页面突然就开始卡得让人怀疑人生？
下一篇
凌晨三点线上报错时，那些所谓的“极客逻辑”全是坑 →
前阵子重构商城模块时，我盯着那满屏乱跳的 DOM 树，一度以为是组件逻辑写得太重。结果按惯例，哪里卡就往哪里套 React.memo，本以为能稳住渲染，没想到反而因为 props 对比的开销，让原本简单的更新变得更沉重了。这就陷入了一个死循环：你以为在优化，其实是在给 CPU 增加无效负担。
我当时直接打开 React DevTools Profiler 看了火焰图，真相瞬间大白——问题根本不在 ProductCard 本身，而是父组件的状态变更直接把整个子节点树全“拖下水”了。这种层层连锁的无意义渲染，光靠 memo 是救不回来的。
针对这种大数据量列表，我最后的方案是弃用了全量渲染，改用虚拟列表（Virtualization）逻辑，只保证可视区域的节点存在，滚动时动态替换。如果你的业务场景确实存在高频交互，我建议配合 useTransition 来标记非紧急更新，把 UI 响应的优先级拉开。
别再凭“感觉”去写优化代码了，工程落地的本质是数据驱动。在动手改代码前，先看看 Profiler 的录制数据，到底是谁在触发 re-render，这才是解决问题的唯一准则。
