企业官网建设流程全解析

• 前端
• 教程

导读

本篇文章源自当前仓库中收录的 Vercel React 最佳实践规则（见 .agents/skills/vercel-react-best-practices/rules/rerender-lazy-state-init.md），深入讲解useState的**懒初始化（lazy initialization）**写法：当初始状态需要昂贵计算时，应传入初始化函数而非直接传入计算结果。读完本文，你将掌握函数式初始化的正确姿势、适用与不适用场景、以及它与函数式更新（functional setState）、派生状态等姊妹规则如何协同，能直接在面试答题与日常编码中落地。

一、问题本质：useState的两个传参形式差异

useState接收一个参数：状态的初始值（这一点在仓库的 useState 基础问答 中也有说明——它接收初始值，返回[value, setter]数组，setter 可以传入新值或函数）。但这里藏着一个容易被忽略的性能细节：

// 形式一：直接传值 const [state, setState] = useState(expensiveValue) // 形式二：传初始化函数（懒初始化） const [state, setState] = useState(() => expensiveValue)

关键区别在于 JavaScript 的求值时机：

• 形式一：expensiveValue这个表达式在每一次渲染时都会被求值。React 虽然只在首次渲染时使用这个值，但参数在调用useState之前就已经被 JS 计算出来了——后续渲染中这份计算被白白浪费。
• 形式二：React 保存的是这个函数本身，只在首次渲染（挂载）时调用它一次，之后不再调用，计算结果被复用于整个组件生命周期。

这正是该规则 frontmatter 中impactDescription所标注的问题："wasted computation on every render"（每次渲染都在浪费计算），影响级别为 MEDIUM，归类在 Re-render Optimization（重渲染优化）板块。

二、反面示例：昂贵计算在每次渲染中重复执行

规则文件给出了两组典型错误写法。

示例 1：构建搜索索引

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

buildSearchIndex(items)很可能是一个遍历大量数据、构建哈希表/倒排索引的昂贵操作。每次query变化导致组件重渲染时，它都会重新执行，但结果根本不会被使用——因为useState只在首次渲染读取初始值。

示例 2：解析 localStorage 中的配置

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

JSON.parse本身不便宜，localStorage.getItem还伴随同步 IO。每次父组件重渲染或settings更新触发的渲染中，这段解析代码都会重复执行——纯粹是浪费。

三、正确写法：函数形式只在首次渲染运行

规则文件给出对应的修正版本，核心改动就是把表达式换成函数：

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} /> }

注意第二个示例的写法：初始化函数内部自行处理「无缓存值」的兜底逻辑（stored ? JSON.parse(stored) : {}），并把整个读取-解析过程收敛到一次执行里。这与仓库中 client-localstorage-schema 等客户端存储相关规则倡导的「减少 localStorage 读取次数」思路一脉相承。

关于执行时机的准确表述：React 会在挂载时调用一次初始化函数并保存其结果；之后无论组件重渲染多少次，都不会再次调用该函数。这确保了昂贵计算在整个组件生命周期中只付出一次成本。

四、什么时候该用懒初始化

规则文件明确给出了适用场景，可归纳为四类：

一句话判断标准：只要初始值的计算成本不低，就应该用函数形式把它推迟到「且仅在」首次渲染时执行。

五、什么时候不需要函数形式

规则文件同时划出了边界——懒初始化不是无脑套用，对以下情况函数形式没有必要：

// 简单原始值：直接传 useState(0) // 直接引用 props：直接传 useState(props.value) // 廉价字面量：直接传 useState({})

原因很简单：这些初始值的求值成本几乎为零，写成() => 0反而增加噪音、降低可读性。特别是useState(props.value)这类直接引用，它只是「把这个值作为初始值快照」，并不代表 React 会跟踪 props 的变化（后续 props 变化需要靠key重置或派生状态处理，相关讨论可参考 se-puede-inicializar-un-estado-con-el-valor-de-una-prop）。

从源码结构看，这条规则的判定逻辑很直白：权衡「求值成本」与「渲染次数」——只有成本显著且渲染频繁时，函数形式才带来可感知的收益。

六、这条规则在最佳实践体系中的位置

该规则不是孤立的技巧，而是 Vercel React 最佳实践技能包（见 .agents/skills/vercel-react-best-practices/SKILL.md）中Re-render Optimization（重渲染优化）板块的第 5 类规则之一，完整体系共 8 个分类、69 条规则，按影响优先级排序。每条规则都遵循统一模板（见 rules/_template.md）：frontmatter 标注标题、影响级别与标签，正文给出「错误写法 / 正确写法 + 解释」的对照结构，便于 Agent 与开发者检索引用。

与本主题最相关的姊妹规则包括：

• rerender-functional-setstate.md：状态更新时使用函数式 setState（setItems(curr => ...)），保证回调引用稳定、避免 stale closure。初始化用懒初始化函数，更新用函数式 setState——两者一个管「初始值的延迟计算」，一个管「更新时基于最新值计算」，恰好覆盖状态生命周期的两端。
• rerender-derived-state-no-effect.md：能从 props/state 推导出的值不要存进 state、更不要在 effect 里 setState，直接在渲染期计算。这提醒我们：懒初始化只解决「一次性的昂贵初始值」，可推导的中间值应走派生计算而非状态，三者在面试追问「如何优化重渲染」时可以串成完整答案。

七、需要注意的边界与陷阱

1. Strict Mode 下初始化函数会被调用两次

React 官方文档明确：在开发模式下，Strict Mode 会额外调用一次初始化函数，以帮助开发者发现不纯的初始化逻辑（仓库中 que-es-el-strict-mode 等问答也覆盖了 Strict Mode 双渲染机制）。因此初始化函数必须是纯函数——不要在里面修改外部变量、产生副作用；读取localStorage、JSON.parse这类幂等读取是安全的，但「写入操作」「递增计数器」这类副作用则不应出现在初始化函数中。

2. 初始值本身是函数时的包裹问题

如果初始状态的值本身就是一个函数（例如要存一个回调），直接写useState(() => myFunction)会被 React 当作「初始化函数」而非「初始值」，导致初始值变成myFunction的执行结果。此时需要再包一层：

// 正确：初始状态是一个函数 const [fn, setFn] = useState(() => () => myFunction)

这是一个经典的面试陷阱，恰好与懒初始化的主题强相关。

3. 与 React Compiler 的关系

与函数式 setState 类似，即便项目启用了 React Compiler（仓库 que-es-el-react-compiler 有相关问答），显式的懒初始化仍然是推荐的、语义清晰的写法——它不依赖编译器优化，任何时候都成立。

八、面试要点速记

• 核心一句话：useState(() => 昂贵计算)让初始化计算只在首次渲染执行；useState(昂贵计算)会让表达式在每次渲染都被求值。
• 原理：JS 先求值参数再调用函数，直接传值意味着「每次渲染都算一遍，结果只被用一次」。
• 典型场景：localStorage 解析、构建索引/Map、读取 DOM、重量级变换。
• 无需场景：useState(0)、useState(props.value)、useState({})等低成本初始值。
• 延伸考点：初始化函数须纯净（Strict Mode 会双调用）；初始值是函数时要双重包裹；配合函数式 setState 与渲染期派生状态，构成完整的重渲染优化体系。

掌握这条规则，你不仅能在面试中准确回答「为什么 useState 要传函数」这类问题，还能在实际项目中消除一类隐蔽的重复计算——每减少一次不必要的昂贵求值，都意味着更快的渲染与更流畅的交互。

• 前端
• 教程