写过一段时间React的人大概都有类似经历：好几个组件里都有一模一样的请求 loading 状态处理，或者都有监听窗口 resize 的代码，复制粘贴几次之后，一旦逻辑要改，就得挨个组件找一遍。这类问题的根源在于状态逻辑没有和视图分离。自定义Hooks正是解决这个问题的官方方案，它允许你把组件内部的状态与副作用抽成一个独立函数，哪个组件需要就在哪里调用。这篇文章从可复用的逻辑类型讲起，配合完整示例，再总结开发规范与常见坑。
哪些逻辑适合抽成自定义Hooks
判断一段逻辑值不值得抽离，核心标准是它是否跨越多个组件重复出现，或者是否本身足够独立、与具体视图无关。一般来说，以下几类逻辑最适合封装：
- 状态逻辑：比如受控表单的字段值管理、多步流程的步骤切换、开关弹窗的可见状态。
- 副作用逻辑：订阅事件、定时器、网络请求、操作localStorage等，这类逻辑往往还需要清理，封装价值很高。
- 性能优化逻辑：防抖、节流、缓存计算结果，抽出来之后可以反复使用。
反过来，如果一段逻辑只服务某一个特定组件、且与渲染结构强耦合，强行抽离只会增加阅读跳转成本。封装前不妨问自己一句：换一个组件，这段代码能不加修改直接用吗？答案是否定的，就先别抽。
三个典型场景的完整实现
1. 表单控制：useForm
受控表单的样板代码非常多，每个字段都要绑定value和onChange。把它们收敛到一个Hooks里，组件就只剩渲染职责：
import { useState, useCallback } from 'react';
function useForm(initialValues = {}) {
const [values, setValues] = useState(initialValues);
// 统一处理字段变化，支持原生事件和直接传值两种形式
const handleChange = useCallback((e) => {
const { name, value } = e.target ? e.target : e;
setValues((prev) => ({ ...prev, [name]: value }));
}, []);
const reset = useCallback(() => setValues(initialValues), []);
return { values, handleChange, reset };
}
// 使用方式
function LoginPanel() {
const { values, handleChange, reset } = useForm({ username: '', password: '' });
return (
<form onSubmit={(e) => { e.preventDefault(); reset(); }}>
<input name="username" value={values.username} onChange={handleChange} />
<input name="password" value={values.password} onChange={handleChange} />
<button type="submit">提交</button>
</form>
);
}这个实现的关键在于handleChange内部通过name属性定位字段，组件不需要为每个输入框单独写回调。initialValues被闭包捕获，reset时可以直接回到初始状态。
2. 窗口尺寸监听：useWindowSize
监听resize是典型副作用场景，重点是必须返回清理函数，否则组件卸载后监听器还挂着，会造成内存泄漏：
import { useState, useEffect } from 'react';
function useWindowSize() {
const [size, setSize] = useState({
width: window.innerWidth,
height: window.innerHeight,
});
useEffect(() => {
const onResize = () => setSize({ width: window.innerWidth, height: window.innerHeight });
window.addEventListener('resize', onResize);
// 清理函数：组件卸载时移除监听
return () => window.removeEventListener('resize', onResize);
}, []);
return size;
}依赖数组留空表示只在挂载时绑定一次。所有涉及addEventListener、setInterval、WebSocket连接的Hooks，都应该遵循同样的模式：在useEffect中开启，在返回的函数中关闭。
3. 防抖值：useDebounce
搜索框输入时频繁触发请求是常见问题，用防抖值可以推迟请求发起：
import { useState, useEffect } from 'react';
function useDebounce(value, delay = 300) {
const [debounced, setDebounced] = useState(value);
useEffect(() => {
const timer = setTimeout(() => setDebounced(value), delay);
return () => clearTimeout(timer);
}, [value, delay]);
return debounced;
}
// 配合搜索使用
function SearchBox() {
const [keyword, setKeyword] = useState('');
const debouncedKeyword = useDebounce(keyword, 500);
useEffect(() => {
if (debouncedKeyword) {
// 只在停止输入500毫秒后执行一次请求
console.log('发起搜索：', debouncedKeyword);
}
}, [debouncedKeyword]);
return <input value={keyword} onChange={(e) => setKeyword(e.target.value)} />;
}注意这里每次value变化都会先清掉上一个定时器，这是防抖语义的核心。清理函数在这里同样不可省略，否则多次输入会触发多次请求，防抖就失效了。
开发规范与最佳实践
命名必须以use开头。这不只是约定，React的Lint插件依赖这个前缀来校验Hooks调用规则。如果你写了一个内部调用了useState的函数却不叫useXxx，ESLint无法帮你检查它在条件分支中被调用的问题，运行时会出现 hooks 调用顺序错乱的报错。
保持输入输出纯粹的数据流。一个设计良好的Hooks应该接收基本值或函数作为参数，返回状态和操作方法，而不是去直接操作DOM或者调用其他组件的方法。返回值建议用对象而不是数组，调用方可以按需解构，后续增加返回字段也不会破坏已有调用。
认真对待依赖数组。useEffect和useCallback的依赖写不写、写什么，直接决定逻辑是否正确。一个实用技巧是把将来会被用到的外部变量全部列入依赖，然后借助eslint-plugin-react-hooks的exhaustive-deps规则自动补全，不要凭感觉省略。如果某个值确实不想触发重新执行，应该用useRef保存或者用函数式更新规避，而不是硬从依赖里删掉。
把复杂Hooks拆小。一个Hooks只做一件事。比如useFetch里如果既包含请求逻辑又包含轮询又包含分页，不如拆成useFetch、usePolling、usePagination三层组合，小单元更容易测试，组合起来也更灵活。
常见的坑与排查思路
第一个坑是在条件或循环中调用Hooks。React靠调用顺序关联状态，一旦某次渲染少调了一个Hooks，后续全部错位，报错信息往往是难以定位的状态异常。只要函数以use开头，就只能在组件顶层调用。
第二个坑是把Hooks当成普通函数在组件外调用。有人会把useXXX写进工具函数甚至在事件回调里调用，这同样违反调用规则。Hooks只能出现在React函数组件或其他自定义Hooks的顶层。
第三个坑是返回函数没有用useCallback包裹。如果Hooks返回的处理函数每次渲染都是新引用，使用它的组件里一旦把这个函数放进useEffect依赖或传给做过memo的子组件，优化就会全部失效，造成不必要的重复执行或重渲染。
最后一个坑是在Hooks里返回JSX当组件用。自定义Hooks返回的应该是数据和行为，渲染结构留给组件。如果发现自己在Hooks里拼接了大量视图，那说明职责边界已经模糊，应该考虑拆组件而不是继续堆Hooks。
掌握了这些原则之后，建议回头审视自己项目里的重复代码，从最简单的一个场景开始抽离，比如先把所有组件里的loading处理收敛成一个useRequest。逻辑复用这件事，收益会随着抽离数量的增加而复利式增长。
自定义HooksReact Hooks逻辑复用修改时间：2026-09-12 18:20:37