React useState 惰性初始化（Lazy State Initialization）实战指南：杜绝每次渲染的无效计算

React useState 惰性初始化（Lazy State Initialization）实战指南：杜绝每次渲染的无效计算

【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy

useState惰性初始化是 Vercel React 性能优化规则集中一项MEDIUM 影响级别的 Re-render Optimization 规则（见 rerender-lazy-state-init.md，其 impactDescription 为 "wasted computation on every render"）。本指南将完整讲解「把函数传给useState替代直接传值」的写法差异、适用场景与反例，并结合当前仓库 cal.diy（开源日程/预订调度应用）中的真实组件源码，说明这条规则在大型 React 应用中的落地形态。读完本文，你将能够准确识别useState初始化中的无意义重复计算，并写出只执行一次初始化的高性能组件。

规则速览

先看规则文件的元数据，它精准概括了本条规则的定位：

字段	值
规则主题	Use Lazy State Initialization（对昂贵的初始值向useState传入函数）
影响级别	MEDIUM
影响描述	每次渲染的无效计算（wasted computation on every render）
标签	react, hooks, useState, performance, initialization

在 Vercel React Best Practices 技能中，本条规则属于第 5 类Re-render Optimization（MEDIUM），其相邻规则（如同类下的 rerender-functional-setstate、rerender-memo、rerender-defer-reads 等，完整清单见 SKILL.md）共同服务于「减少不必要的组件重复渲染与重复计算」这一目标。该技能包共含 8 类 45 条规则，本规则聚焦于useState初始值这一最基础也最容易被忽视的环节。

核心原理：为什么直接传值会让初始化器「每次渲染都跑」

React 中useState(initialValue)的initialValue参数只在首次挂载时被读取一次并作为初始状态，理论上后续渲染应不再使用它。然而，React 并不具备魔法——它无法知道你传入的表达式是否昂贵，于是每次渲染都会照常执行这段表达式求值，只是求值结果被丢弃而已。

规则原文将其表述为：

Pass a function touseStatefor expensive initial values. Without the function form, the initializer runs on every render even though the value is only used once.

（对于昂贵的初始值，请向useState传函数。如果不使用函数形式，初始化器会在每次渲染时都执行，尽管该值实际上只会被使用一次。）

两个典型的反面示例

规则文档给出了两个极易出现在真实项目中的反例。第一个是把构建数据结构这样有明显计算量的函数直接塞进useState：

function FilteredList({ items }: { items: Item[] }) { // buildSearchIndex() 在每次渲染时都会执行，即便是在初始化完成之后 const [searchIndex, setSearchIndex] = useState(buildSearchIndex(items)) const [query, setQuery] = useState('') // 当 query 变化触发重渲染时，buildSearchIndex 会再次白白执行 return <SearchResults index={searchIndex} query={query} /> }

这里的items不变、searchIndex本身也没有被更新，但每当query变化导致组件重渲染，buildSearchIndex(items)这一整棵搜索索引的构建工作都会被重复执行一遍——query的每一次击键都附带一次本可完全省略的索引重建。

第二个反例直击前端最常见的localStorage读取 +JSON.parse反序列化：

function UserProfile() { // JSON.parse 在每次渲染时都会执行 const [settings, setSettings] = useState( JSON.parse(localStorage.getItem('settings') || '{}') ) return <SettingsForm settings={settings} onChange={setSettings} /> }

localStorage.getItem是同步的磁盘/存储读取，JSON.parse需要对整个字符串做语法解析。二者组合每次渲染都会产生一次真实的 I/O 与 CPU 开销。若该组件位于高频更新的页面，代价会被放大。

致命点总结

无论是buildSearchIndex(items)、JSON.parse(...)，还是任何函数调用表达式，直接放在useState(...)的参数位置上时，它们都只是「一个会被求值的 JSX 表达式」，React 无法识别其是否需要惰性求值。性能与正确性层面的问题包括：

1. 无意义计算：重渲染（例如父组件传参变化、兄弟状态变化、context 更新）会反复触发昂贵初始化器的执行；
2. 可观测副作用被重复执行：若初始化器内部带有console、订阅、随机数等，其调用次数将超出预期，给调试与测试带来困惑；
3. 放大问题：初始化器引用的 props/外部值越大、计算越复杂，浪费越明显。

正确姿势：传入函数，让初始化「只运行一次」

把「值」换成「返回值的函数」，React 便只会在首次渲染时调用一次该函数，并将其返回值作为初始 state，后续渲染一律不再调用。

规则文档给出的正确示例：

function FilteredList({ items }: { items: Item[] }) { // buildSearchIndex() 仅在首次渲染时执行 const [searchIndex, setSearchIndex] = useState(() => buildSearchIndex(items)) const [query, setQuery] = useState('') return <SearchResults index={searchIndex} query={query} /> } function UserProfile() { // JSON.parse 只在首次渲染时执行 const [settings, setSettings] = useState(() => { const stored = localStorage.getItem('settings') return stored ? JSON.parse(stored) : {} }) return <SettingsForm settings={settings} onChange={setSettings} /> }

注意UserProfile的正确写法还顺带修复了原反例的一个小隐患：localStorage.getItem('settings') || '{}'在值为合法但为空的字符串（如''）时语义会产生偏移，改为先取出stored再条件解析后，空字符串会直接落入{}分支，语义更严谨。

两者对比速查

写法	函数形式	首次渲染	后续每次渲染
useState(buildSearchIndex(items))	❌ 否	执行初始化器	仍执行初始化器（结果被丢弃）
useState(() => buildSearchIndex(items))	✅ 是	执行一次	不再执行

何时必须使用惰性初始化

规则文档明确指出，当初始值来自以下渠道时，应使用函数形式：

• 读取localStorage/sessionStorage：同步存储 I/O 加字符串解析；
• 构建数据结构：如索引（indexes）、Map、Set等需要遍历数据组装的对象；
• 读取 DOM：例如基于window.innerWidth、document.querySelector或元素尺寸计算初始值；
• 执行重量级转换：大数组的filter/sort/groupBy、JSON 反序列化、加解密、时间/时区换算等。

一个通用的判断标准是：如果初始化表达式里出现了函数调用，而这个函数调用「有真实工作量」或「有 I/O」，就应默认使用惰性初始化写法。

不需要函数形式的场景

规则文档同时给出了豁免清单——这些场景下函数形式是多余的，强行套用反而降低可读性：

• 简单原始值：如useState(0)、useState('')、useState(false)，求值开销可忽略；
• 直接引用：如useState(props.value)，只是读取一个已存在于内存中的值；
• 廉价字面量：如useState({})、useState([])。

值得强调的是：useState({})或useState([])这类「每次渲染新对象字面量被创建」的写法虽然在初始化语义上没有浪费，但其每次重渲染创建新引用的行为恰恰会被 React 的 referential equality 比较放大（例如作为 effect 依赖或 memo 子组件的 props 时会引发连锁重渲染）——这是另一条规则的领域，但在工程实践中二者常被同时审视。

仓库实战：cal.diy 中的两处真实惰性初始化

规则不只停留在文档层面。在当前仓库 cal.diy 中，可以找到与规则描述完全对应的真实实现，印证其工程价值。

示例一：预约录制视频页的进度条组件

在 apps/web/modules/videos/views/videos-single-view.tsx 中，ProgressBar组件需要在挂载时基于「当前时间与录制起止时间」推算初始剩余时长，涉及dayjs的多重时间运算：

const [duration, setDuration] = useState(() => { if (currentDifference >= 0 && isPast) { return startDuration - currentDifference; } else { return startDuration; } });

这段代码的执行环境正是规则强调的「基于当前值/时间做重量级换算」的典型场景：currentTime、startingTime、currentDifference、startDuration均由dayjs()与多次.diff()运算得出。若不使用惰性初始化，这些时间差运算会在组件每次重渲染（例如下方useEffect中setDuration触发状态更新后）被反复重算。此外，同一组件后续以setDuration((prev) => prev - 1)进行函数式更新（见同一文件），恰好与配套规则 rerender-functional-setstate.md 形成完整闭环：用惰性初始化确定起点、用函数式更新推进终点，两种写法协同避免了对旧状态闭包的依赖。

示例二：Booking Details Sheet 的 Zustand 状态仓库创建

在 apps/web/modules/bookings/store/bookingDetailsSheetStore.tsx 中，BookingDetailsSheetStoreProvider以惰性初始化一次性创建全局状态仓库：

export function BookingDetailsSheetStoreProvider({ children, bookings, capabilities }) { const [store] = useState(() => createBookingDetailsSheetStore(bookings)); // ... }

createBookingDetailsSheetStore(bookings)需要遍历预约列表bookings构建完整的 store 对象（含 actions、URL 同步逻辑等）。将该工厂函数包进useState惰性初始化器后，store 在 Provider 首次挂载时被构建一次，后续bookings/capabilities的变化通过独立的useEffect与 ref 比较（previousBookingsRef）增量同步进 store，而不会触发整棵 store 的重复重建。这是大型 React + Zustand 应用中非常标准的惰性初始化用法——把一个「只应该执行一次」的重量级构建与后续渲染彻底解耦。

常见误用排查清单

在代码评审或自查时，可按下述清单快速扫描：

1. useState(的参数位置上是否存在函数调用表达式（如useState(fetchSomething())、useState(parseConfig(x))）？若有，改为useState(() => ...)；
2. 初始化逻辑是否读取了localStorage/sessionStorage或操作了 DOM？若是，务必惰性化；
3. 初始化器内部是否有console.log、事件订阅等副作用？惰性化后这些副作用只触发一次，更符合预期；
4. 是否对廉价字面量误用了函数形式？useState(() => 0)属于过度设计，useState(0)即可；
5. 初始值是否依赖组件 props？惰性初始化器只在首次渲染执行，若后续 props 变化需要重建状态，应放在 effect 或 key 重置逻辑中，而非依赖惰性初始化。

边界与提醒

• 惰性初始化器传入的函数只在首次渲染被调用，因此它内部读取的 props/外部值必须是「首次渲染时就能确定」的；若状态需要随 props 变化而重置，需要结合组件key变更或 effect 同步，而不能指望初始化器重复执行；
• React 在开发模式的 StrictMode 下会双调用初始化器以帮助暴露不纯函数，请勿在初始化器中写入带副作用的逻辑，保持其「纯计算」属性；
• 若项目启用了 React Compiler，编译器可能对部分初始化场景做自动优化（配套规则 rerender-functional-setstate.md 中有相关说明），但对「昂贵的初始化表达式」显式使用惰性写法仍是文档推荐、无副作用且可读性最佳的做法。

结语

useState惰性初始化是 React 性能优化中成本最低、收益最直接的一类改动：不需要任何依赖数组、不需要记忆化缓存、不需要重构组件树，只需在传参位置补一层函数包裹。对 cal.diy 这类依赖localStorage、构建搜索索引/状态仓库、并频繁进行时间计算的复杂调度应用而言，它既避免了每次击键触发的索引重建、存储 I/O 与时间运算，也让初始化逻辑的「仅执行一次」语义在代码层面清晰可见。评审代码时，把「useState参数位是否出现了函数调用」作为一条默认检查项，就能持续规避这一类隐藏的无效计算。

进一步阅读：本规则出自 vercel-react-best-practices 技能包，同属 Re-render Optimization 类别的 rerender-functional-setstate.md、rerender-memo.md 与 rerender-derived-state.md 提供了同一性能维度下的互补策略，可一并阅读形成体系。

【免费下载链接】cal.diyScheduling infrastructure for absolutely everyone.项目地址: https://gitcode.com/GitHub_Trending/ca/cal.diy