企业官网建设流程全解析

深入解析 React Effect 反模式：将交互逻辑放入事件处理器（Vercel React Best Practices 实战指南）

【免费下载链接】phoenixAI Observability & Evaluation项目地址: https://gitcode.com/gh_mirrors/phoenix13/phoenix

本文源自当前仓库 Vercel React Best Practices 技能库中的核心规则 rerender-move-effect-to-event.md。该技能库由 Vercel Engineering 维护，收录了 70 余条面向 React/Next.js 的性能优化规则，按影响度分为 8 大类，本规则属于第 5 类"Re-render Optimization"（重渲染优化，影响度为 MEDIUM）。

规则速览：什么情况下必须把副作用搬进事件处理器

当一个副作用（side effect）是由某个明确的用户操作（提交表单、点击按钮、拖拽元素、键盘输入等）触发时，应当在该操作对应的事件处理器（event handler）中直接执行它，而不要把"用户执行了操作"建模为一个 state 再交给useEffect去响应。后者会让 effect 在无关状态变更时被反复触发，并可能导致同一个副作用被重复执行。

这是 React 官方"移除 effect 依赖"指南中的一个经典判例：Should this code move to an event handler?（这段代码是否应该移到事件处理器中？）。判定标准简单直接：如果某段副作用代码只应当响应用户的一次具体操作而运行一次，它就是事件处理器该做的事，而不是 effect 该做的事。

反模式剖析：用 state + effect 建模一次提交

下面是一个典型的错误写法——把"是否提交"作为布尔 state，再让 effect 监听它：

function Form() { const [submitted, setSubmitted] = useState(false) const theme = useContext(ThemeContext) useEffect(() => { if (submitted) { post('/api/register') showToast('Registered', theme) } }, [submitted, theme]) return <button onClick={() => setSubmitted(true)}>Submit</button> }

这段代码存在两个问题：

1. 依赖数组使 effect 在无关变更时重复运行：effect 的依赖是[submitted, theme]。theme来自ThemeContext，它并不代表"提交"这个动作，但只要主题上下文发生变化，effect 就会重新运行并再次调用post('/api/register')——用户可能被重复注册。这正是本技能库中 rerender-dependencies.md 强调的问题：effect 依赖越宽，越容易被无关变更重新触发。
2. 语义错位：submitted这个 state 除了"通知 effect 执行一次副作用"之外没有其他用途，它是为 effect 而存在的"中间人"。副作用本身并没有消费任何"随时间变化"的数据，它只是响应一次点击。

正确范式：副作用直接放进事件处理器

function Form() { const theme = useContext(ThemeContext) function handleSubmit() { post('/api/register') showToast('Registered', theme) } return <button onClick={handleSubmit}>Submit</button> }

改写后的行为完全符合预期：

• post('/api/register')和showToast(...)只会在用户点击按钮时执行一次；
• 组件不再维护多余的submittedstate，少了一次 state 写入就少触发一次重渲染；
• 不再有依赖数组，theme或其他上下文的任何变化都不会误触发副作用；
• 事件处理器总是从最新一次的渲染闭包中读取theme，不存在陈旧值问题。

从重渲染优化的角度看，这个改写同时消除了两类开销：一是去掉了多余的 state 更新与随之而来的重渲染，二是让副作用与组件的渲染生命周期彻底解耦。

背后的原理：为什么 effect 会"多跑"和"重跑"

要真正理解这条规则，需要澄清 effect 的两个行为特性：

1. effect 可能执行多次（重跑）useEffect的依赖数组采用引用/值比较，数组中任何一个依赖项发生变化，React 就会先执行上一次 effect 的清理函数，再重新执行 effect。因此，任何被塞进依赖数组的无关值（如theme）都等于给副作用装了一个"意外扳机"。

2. 开发环境下 effect 会被有意地双执行React 在开发模式（配合<StrictMode>）下会故意把 effect 挂载→卸载→再挂载，以便暴露未正确清理的副作用。也就是说，把"提交注册"这种不可幂等的操作放进 effect，即使在依赖数组完全正确的情况下，开发环境里也可能看到副作用执行两次；而事件处理器永远不会被 React 以这种方式重复调用。把操作放入事件处理器，是让"一次用户操作 = 一次副作用"的唯一可靠保证。

3. effect 是渲染后的异步补丁，事件处理器是交互的同步应答Effect 在浏览器绘制后运行，用于把组件与外部系统（订阅、计时器、网络请求等）同步；而事件处理器直接对应一次用户意图。前者适合"持续存在的关系"，后者适合"一次性动作"。

何时该用事件处理器、何时该保留 effect：判定清单

核心判据来自本规则的标题本身：这段副作用代码是否绑定在一个具体的用户动作上？是——进事件处理器；否（它是对某个持续变化的数据流的响应）——保留 effect，同时遵循 rerender-dependencies.md 的"收窄依赖"原则：

// 属于"持续响应"，保留 effect，但依赖用原始值收窄 const isMobile = width < 768 useEffect(() => { if (isMobile) { enableMobileMode() } }, [isMobile]) // 只在该布尔值翻转时触发，而不是每次 width 变化

与技能库中相邻规则的配合使用

这条规则不是孤立的，它与本技能库 Re-render 优化分类（SKILL.md 第 5 节）中的其他规则共同构成一套完整的"去 effect 化"方法论：

• rerender-derived-state-no-effect.md：如果值能从现有 props/state 计算得出，就在渲染期间直接推导，而不是存进 state 再靠 effect 同步。与本规则同理——能省掉的 effect 就不要创建。
• rerender-functional-setstate.md：事件处理器内若需要基于当前 state 更新状态，应使用函数式更新（setItems(curr => ...)），避免把 state 值放进依赖数组造成闭包陈旧或回调频繁重建。
• rerender-dependencies.md：对于确实需要保留的 effect，依赖必须收窄到原始值/布尔派生值，减少重跑机会。
• advanced-effect-event-deps.md与advanced-event-handler-refs.md：在"必须在 effect 内部注册回调（如订阅事件源），但回调要读取最新值"的少数场景中，使用useEffectEvent或在 ref 中保存最新 handler，避免把回调函数本身放入依赖数组导致 effect 每次渲染都重订阅——这是"事件处理器优先"原则在 effect 边界内的延伸解法。

例如，监听窗口事件的 hook 若把 handler 直接放进依赖数组，会在每次渲染后重新订阅；改用 ref 或useEffectEvent后订阅只依赖event名称，稳定且不会漏读最新 handler：

import { useEffect, useEffectEvent } from 'react' function useWindowEvent(event: string, handler: (e: Event) => void) { const onEvent = useEffectEvent(handler) useEffect(() => { window.addEventListener(event, onEvent) return () => window.removeEventListener(event, onEvent) }, [event]) // 注意：依赖数组里是 event，不是 onEvent }

实战自查清单

在代码评审或重构时，遇到useEffect可以先问自己四个问题（对应规则原文件的判定要点）：

1. 触发源是谁？如果只有"用户点了某个按钮/提交了表单"才会需要执行，立刻把逻辑搬进事件处理器；
2. 依赖数组里有没有"陪跑"依赖？如果有与副作用无关的上下文值，说明这个 effect 本就不该存在，或需要像收窄[submitted, theme]那样大幅收窄；
3. 这个 state 是不是只为 effect 而生？如果删掉它 effect 就不需要了，说明它是多余的"中间人"状态，应一并删除；
4. 开发环境双执行能否接受？提交、支付、发送通知等不可幂等的操作放在 effect 里，在 StrictMode 下可能被调用两次，事件处理器是更安全的落点。

结语

"把交互逻辑放进事件处理器"是 React 组件开发中性价比最高的性能与正确性改进之一：它同时减少了 state 数量、减少了重渲染次数、消除了依赖数组带来的意外副作用重跑，并保证了"一次操作只产生一次副作用"的语义。在维护 React/Next.js 代码库时，将这条规则与 rerender-derived-state-no-effect.md、rerender-dependencies.md、rerender-functional-setstate.md 等规则组合使用，即可系统性地消除由错误 effect 用法带来的重渲染与重复副作用问题。完整规则集可在仓库 .agents/skills/vercel-react-best-practices/ 目录下查看。

【免费下载链接】phoenixAI Observability & Evaluation项目地址: https://gitcode.com/gh_mirrors/phoenix13/phoenix