Vue3自定义Hooks实战：从useTable到useRequest的封装与复用-北京尧图网络

去年团队接到一个后台管理系统重构光是搜索表格这类页面就有二十几个。某个版本上线前我随手搜了一下代码库里复制粘贴的列表请求逻辑结果搜出来十几份几乎一模一样的loading、page、data状态管理代码。那时候团队里大多数人还在用 Options API 写业务组件之间复用逻辑基本靠 mixin 和工具函数硬凑。后来我们逐步把 Vue3 组合式 API 用起来核心抓手就是自定义 Hooks。这篇文章就把我这段时间在 Vue3 里封装和使用自定义 Hooks 的完整心得写出来包括设计思路、完整代码、踩坑记录以及怎么在团队里把 Hooks 这套东西落地。适合已经能熟练写 Vue3 基础、但还没系统整理过自定义 Hooks 的同学也适合想在项目里推进组合式 API 复用的技术负责人参考。1. 复制粘贴了五遍之后我才开始理解自定义 Hooks1.1 一个让人无语的代码复制现场事情是这样的。我们的系统里有一个用户管理页面功能非常标准顶部搜索栏中间表格底部翻页器。大概长这样template div el-form :inlinetrue el-input v-modelquery.keyword placeholder用户名 / el-button clickhandleSearch搜索/el-button el-button clickhandleReset重置/el-button /el-form el-table :datalist v-loadingloading !-- 列配置 -- /el-table el-pagination :current-pagepage :page-sizepageSize :totaltotal current-changehandlePageChange / /div /template刚接手时我在这个文件里看到了这样一段代码const list ref([]) const loading ref(false) const page ref(1) const pageSize ref(10) const total ref(0) const query reactive({ keyword: }) async function getList() { loading.value true try { const res await fetchList({ page: page.value, pageSize: pageSize.value, ...query }) list.value res.data.rows total.value res.data.total } finally { loading.value false } } function handleSearch() { page.value 1 getList() } function handleReset() { query.keyword page.value 1 getList() } function handlePageChange(p) { page.value p getList() } getList()坦白讲这段代码写得还算规矩。问题在于——类似这样的逻辑在系统里出现了十几次。每个页面都重新写一遍list、loading、page、pageSize、total每个页面都写一遍getList、handleSearch、handleReset、handlePageChange。有同事图省事直接把整个组件的 script 复制过去改两行完事。复制粘贴的后果很快显现了某次接口数据结构调整后端把rows改成了records。我们全局搜字段名光列表接口就改了八处累得够呛。那段时间我就在想能不能抽出一套东西把这种带响应式状态的逻辑真正复用起来而不是复用一段文本。1.2 工具函数为什么救不了带状态的逻辑很多人第一反应是把请求逻辑抽成工具函数不就行了确实可以。我们当时的工具函数长这样export async function fetchUserList(params) { return http.get(/user/list, { params }) }这个工具函数能复用的是接口调用但它解决不了组件里的loading、list、total这些响应式状态。因为这些状态和组件的生命周期绑定在一起而且它们彼此之间是有联动关系的请求开始要loading true请求结束要loading false拿到total要更新分页。你可以把每个函数包装成独立工具但状态之间的联动逻辑没法靠工具函数表达。换句话说工具函数适合封装输入-输出明确的纯逻辑比如日期格式化、数组去重。而带状态的 UI 逻辑比如加载中、有没有数据、错误信息是什么它们天然是响应式的需要一套能和组件渲染绑定的机制来处理。这就是自定义 Hooks 登场的背景。在 Vue3 里它其实就是组合式 API 的函数化封装把一组相关的响应式状态连同修改这些状态的函数打包进一个可复用的函数里。1.3 mixin 的老账来自 Options API 时代的前车之鉴在 Vue2 时代复用带状态逻辑的官方方案是 mixin。我见过不少项目把 mixin 用成了维护噩梦。举几个真实例子第一命名冲突不可控。两个 mixin 都定义了一个getList方法组件的methods里再定义一个最终生效的是谁规则是有的但排查成本很高。尤其是当 mixin 传了好几层你要去看 mixin 源码才知道数据是从哪来的。第二来源不清晰。模板里突然出现一个this.total这是一个 data 字段、一个 computed、还是一个 mixin 里提供的不翻代码根本不知道。如果 mixin 里改了某个 data 字段只影响这个组件还好但它要是间接改了别的共享对象排查起来真是一场灾难。第三隐式共享状态。有些同学会在 mixin 外面定义共享对象给多个组件用这比不用 mixin 还危险。组件 A 改了它组件 B 的展示就变了而这种跨组件的隐式通信几乎没有可追踪性。我见过最夸张的一个 mixin 有八百多行同时被十几个组件引用。那个项目最后没人敢动它动了就牵连一片。自定义 Hooks 在一定程度上解决了这些问题因为它的数据流是显式传递的组件里明确知道调用了哪个 Hooks也知道它返回了哪些状态。2. 自定义 Hooks 的底层逻辑组合式 API 的工程化输出2.1 它本质上就是把逻辑和模板拆开Vue3 的组合式 API 把 Options API 里按选项组织代码的方式改成了按功能组织代码的方式。在 Options API 里一个功能的数据、计算属性、方法、watch 被拆散到data、computed、methods、watch各个选项里而在组合式 API 里它们可以放在一起。// Options API 时代一个搜索功能被拆成四块 export default { data() { return { list: [], loading: false, page: 1 } }, computed: { hasMore() { return this.list.length this.total } }, methods: { async getList() { this.loading true this.list await fetchList() this.loading false } }, watch: { keyword() { this.getList() } } }// 组合式 API 时代同一块逻辑可以紧凑地放在一起 export function useList() { const list ref([]) const loading ref(false) const page ref(1) async function getList() { loading.value true list.value await fetchList() loading.value false } watch(page, getList) return { list, loading, page, getList } }自定义 Hooks 就是在这个基础上进一步把某一种业务能力抽成独立函数。它的价值不在于写法变好看了而在于跨组件复用的单位从整个组件缩小到了一组逻辑。2.2 为什么 Vue 的 Hooks 比 React 更像普通函数写过 React Hooks 的同学上手 Vue3 自定义 Hooks 时会有一个非常强烈的感受太自由了。React 的useState、useEffect有严格的调用顺序要求Hooks 不能写在条件语句里不能在循环里调用否则 hooks 链会错乱。这是 React 的实现机制决定的——它靠调用顺序来记住每个 state 属于哪个组件。Vue3 没有这个限制。原因在于 Vue 的响应式系统是基于 Proxy 的代理式响应每个ref、reactive返回的对象本身就是一个独立的响应式引用。你可以在任意嵌套、循环、条件语句里创建它们没有执行顺序的约束。// React 里这么写会炸 function Component({ flag }) { if (flag) { const [state, setState] useState(0) // Error } }// Vue 里这么写完全没问题 function useTest(flag) { let state null if (flag) { state ref(0) } return state }这个差异让 Vue3 的自定义 Hooks 在实现上更像普通函数组合对开发者的心智负担更小。但也带来一个反面问题正因为太自由很多人会把 Hooks 当成随手抽出的普通工具函数忽略了它作为业务逻辑单元的边界和职责。这个我在后面第 6 节展开说。2.3 一个最小的 useScrollPosition 示例先给一个最小的入门示例让还没写过自定义 Hooks 的同学感受一下它的基本形态。需求很简单监听页面滚动返回滚动位置。import { ref, onMounted, onUnmounted } from vue export function useScrollPosition() { const scrollX ref(0) const scrollY ref(0) function updatePosition() { scrollX.value window.scrollX scrollY.value window.scrollY } onMounted(() { window.addEventListener(scroll, updatePosition) updatePosition() }) onUnmounted(() { window.removeEventListener(scroll, updatePosition) }) return { scrollX, scrollY } }组件里这样用script setup import { useScrollPosition } from /hooks/useScrollPosition const { scrollX, scrollY } useScrollPosition() /script template div当前位置{{ scrollX }}, {{ scrollY }}/div /template这个例子虽然简单但已经包含了自定义 Hooks 的全部核心要素用ref创建响应式状态、用onMounted/onUnmounted管理副作用、返回状态给组件使用。组件里拿到的scrollX和scrollY是响应式的模板里可以直接绑定。3. 手写 useTable搜索、分页、刷新一体的后台表格 Hooks3.1 需求拆解一个后台表格到底要什么状态做后台管理系统的都知道表格页面是最高频的场景。先把需求列清楚表格数据list加载状态loading分页信息page、pageSize、total查询条件query刷新方法refresh重新拉当前页数据搜索方法search重置页码到第 1 页再拉取重置方法reset清空查询条件、重置页码、重新拉取当前选中的行selection有的表格需要多选这些状态和方法是强关联的非常适合封装成一个 Hooks。3.2 先写一个能用版本最开始不必追求通用先把当前页面的逻辑抽出来验证 Hooks 的形式是否可行。import { ref, reactive } from vue export function useTable(api, initialQuery {}) { const list ref([]) const loading ref(false) const page ref(1) const pageSize ref(10) const total ref(0) const query reactive({ ...initialQuery }) async function loadList() { loading.value true try { const res await api({ page: page.value, pageSize: pageSize.value, ...query }) list.value res.data.rows total.value res.data.total } finally { loading.value false } } function handleSearch() { page.value 1 loadList() } function handleReset() { Object.keys(query).forEach((key) { query[key] undefined }) page.value 1 loadList() } function handlePageChange(p) { page.value p loadList() } loadList() return { list, loading, page, pageSize, total, query, refresh: loadList, search: handleSearch, reset: handleReset, handlePageChange } }组件里的使用方式script setup import { fetchUserList } from /api/user import { useTable } from /hooks/useTable const { list, loading, page, pageSize, total, query, search, reset, handlePageChange } useTable(fetchUserList, { keyword: }) /script这个版本能直接跑。它比复制粘贴好在哪里第一所有和列表请求相关的状态都集中在一个函数里第二下一个页面接过来就能用不用重新声明loading、list、total这些样板状态。3.3 再写一个好用版本支持泛型和配置项能用版本有个问题res.data.rows和res.data.total是写死的字段名。不同后端返回结构可能不一样有的接口直接返回数组有的包了一层{ records, total }。所以好用的版本需要把数据解析交给调用方。另外还要支持一个场景有的页面不是用page/pageSize分页而是直接用pageNum/pageSize。这些参数名差异如果写死在 Hooks 里复用性会大打折扣。于是我把版本升级了一下用泛型约束返回的数据类型用配置项传入分页参数名和解析函数script setup langts genericT import { ref, reactive, onMounted } from vue interface UseTableConfig { api: (params: any) Promiseany params?: Recordstring, any pageField?: string pageSizeField?: string transform?: (res: any) { list: T[]; total: number } /scriptexport function useTableT( config: { api: (params: any) Promiseany params?: Recordstring, any pageField?: string pageSizeField?: string transform?: (res: any) { list: T[]; total: number } } ) { const { api, params {}, pageField page, pageSizeField pageSize, transform (res: any) res.data } config const list refT[]([]) as RefT[] const loading ref(false) const page ref(1) const pageSize ref(10) const total ref(0) const query reactive({ ...params }) async function loadList() { loading.value true try { const res await api({ [pageField]: page.value, [pageSizeField]: pageSize.value, ...query }) const { list: newList, total: newTotal } transform(res) list.value newList total.value newTotal } finally { loading.value false } } // ... 其余方法同上 return { list, loading, page, pageSize, total, query, refresh: loadList, search: handleSearch, reset: handleReset, handlePageChange } }这种写法有一个细节值得注意transform函数的默认值设成(res: any) res.data。因为很多后端接口在data字段里既包含了rows又包含了total{ code: 200, data: { rows: [], total: 0 } }如果你的后端长这样直接传transform: (res) ({ list: res.data.rows, total: res.data.total })就行。如果你的后端直接返回数组transform就写(res) ({ list: res, total: res.length })。这段代码从实际项目里抽出来我自己的体会是Hooks 的配置项设计比 Hooks 本身更重要。因为配置项决定了这个 Hooks 能覆盖多少场景也决定了别人用起来是否顺手。4. useRequest 的封装与竞态处理异步逻辑才是 Hooks 的主战场4.1 useRequest 的基本形态列表页的 Hooks 偏向业务而useRequest是更通用的一层封装。它的目标是把任何异步请求的状态管理抽出来——不管你是请求列表、提交表单还是删除一条数据都能用。基本形态import { ref } from vue export function useRequestT, P extends any[]( fn: (...args: P) PromiseT ) { const data refT | null(null) const loading ref(false) const error refError | null(null) async function run(...args: P) { loading.value true error.value null try { data.value await fn(...args) return data.value } catch (e) { error.value e as Error throw e } finally { loading.value false } } return { data, loading, error, run } }注意这里run函数把fn的返回值透传出去所以调用方既可以通过data读取结果也可以通过await run()拿返回值。这个设计很关键因为有的场景里你需要在请求完成后继续做别的操作比如提交完表单关闭弹窗。4.2 竞态问题为什么要用 AbortController竞态是异步请求里最常见、却最容易被忽略的问题。我举一个真实的例子。用户管理页面有一个搜索框输入关键字后请求用户列表。用户在输入框里快速输入张、张三、张三丰触发了三个请求。这三个请求是并行发出的但返回顺序不一定是发出顺序。如果张的请求最后返回页面就会显示关键字为张三丰的搜索结果却渲染成张的数据。响应拦截器能解决一部分问题但更稳妥的做法是在请求层面取消过期请求。AbortController是浏览器原生 API专门用来中断 fetch 请求。import { ref, onUnmounted } from vue export function useRequestT, P extends any[]( fn: (...args: P) PromiseT, { manual false } {} ) { const data refT | null(null) const loading ref(false) const error refError | null(null) let abortController: AbortController | null null async function run(...args: P) { if (abortController) { abortController.abort() } abortController new AbortController() loading.value true error.value null try { const result await fn(...args, abortController.signal) data.value result return result } catch (e) { if (e instanceof DOMException e.name AbortError) { console.log(请求已取消) return undefined as any } error.value e as Error throw e } finally { loading.value false } } onUnmounted(() { abortController?.abort() }) return { data, loading, error, run } }实际调用时fn需要接受signal参数并把它传给底层请求库。axios 的写法是async function fetchUserList(params, signal) { return http.get(/user/list, { params, signal }) }如果你的项目用的是 axios它原生支持signal选项也就是说不需要改动接口封装只需要在调用时把 signal 透传下去。用了 AbortController 之后快速切换搜索条件时前一个请求会被中断从根源上避免了状态错乱。如果在不支持AbortController的环境下退而求其次可以在 Hooks 里维护一个自增 id每次请求前id 1返回时校验 id 是否匹配不匹配就丢弃结果。原理是一样的——让一次请求的结果只能被当次请求消费。4.3 参数变化时的处理watch 与刷新有些场景需要监听某些响应式值的变化自动重新请求。比如上面提到的用户列表根据路由参数变化自动刷新或者选择不同项目后下面联动列表。一个简单的做法是给useRequest增加一个onWatch选项传入一个响应式源可以是一个 ref、一个 getter 函数、或一个数组Hooks 内部用watch监听并触发run。import { watch, type WatchSource } from vue export function useRequestT, P extends any[]( fn: (...args: P) PromiseT, options: { manual?: boolean watchSource?: WatchSource | WatchSource[] } {} ) { // ... 前面的代码 if (options.watchSource) { watch(options.watchSource, () { run() }) } return { data, loading, error, run } }注意这里run()如果接受不定参数那watch触发的调用就不传参数只依赖响应式源的变化。这种写法适合请求参数完全由响应式状态驱动的场景。还有一个细节watch 默认是惰性的不会在组件初始化时触发。如果你希望在初始化时就执行一次请求可以手动调用run()或者初始化时run()。这个可以根据业务需要自行决定。5. Hooks 的组合玩法把 useTable 和 useRequest 串成一套查询系统5.1 组合是 Hooks 的灵魂从单一功能到业务闭环自定义 Hooks 真正的威力不在于单个 Hooks 多复杂而在于多个 Hooks 可以自由组合形成一个更上层的业务能力。举一个真实项目的例子。后台系统里有一个订单管理页面它的逻辑比普通列表页复杂查询条件包含日期范围、订单状态、城市还有导出当前条件下的全部订单这个按钮。拆解一下这个页面需要的逻辑订单列表的分页查询基础表格逻辑订单状态的选项配置顶级常量/字典逻辑导出功能需要当前查询条件但和分页无关如果直接用useTable导出功能会面临一个问题useTable里的page和pageSize是当前分页但导出要求导出的是当前条件下全部订单不是当前页。这时候有两种做法给useTable增加一个getQueryParams()方法导出时只取查询条件不取分页参数。把查询条件单独抽成一个useQueryHooksuseTable和导出功能都依赖它。我倾向于第二种做法因为它更符合单一职责的拆分思路。来看一下组合出来的结构// useOrderQuery.ts export function useOrderQuery() { const query reactive({ orderNo: , status: , city: , dateRange: [] }) function reset() { Object.assign(query, { orderNo: , status: , city: , dateRange: [] }) } return { query, reset } }// useOrderTable.ts export function useOrderTable(query) { const table useTable( { api: fetchOrderList, params: query } ) return table }script setup const { query, reset: resetQuery } useOrderQuery() const table useOrderTable(query) async function handleExport() { const res await exportOrder({ ...query }) // 触发下载 } function handleReset() { resetQuery() table.search() } /script这样一拆query可以被多个逻辑共享reset的逻辑也统一了。页面里新增的导出按钮只需要依赖query即可不需要关心表格的分页状态。这种组合方式还有一个好处测试方便。useOrderQuery是一个纯 Hooks可以在单测里直接调用并断言reset()后的值。完全不需要 mount 组件。5.2 几个我常用的通用 Hooks 清单除了表格和请求我在项目里还沉淀了一批通用 Hooks按使用频率列一下。useLocalStorage把状态同步到 localStorage刷新后自动恢复。import { ref, watch } from vue export function useLocalStorage(key, defaultValue) { const data ref(JSON.parse(localStorage.getItem(key)) ?? defaultValue) watch(data, (val) { localStorage.setItem(key, JSON.stringify(val)) }, { deep: true }) return data }useEventListener统一的事件监听 Hook自动在卸载时移除。它背后的原理很简单就是封装addEventListener和removeEventListener但好处是组件里不用再手写onUnmounted了减少遗漏。useDebounce输入框防抖。表单搜索里非常常用。import { ref, watch } from vue export function useDebounce(value, delay 300) { const debouncedValue ref(value.value) watch(value, (newValue) { const timer setTimeout(() { debouncedValue.value newValue }, delay) // 这里需要清理 timer防止前一次未执行的 timer 修改最新值 // 注意不能在 watch 回调里用 onUnmounted 清理因为回调生命周期已结束 // 正确做法是用一个外层变量保存 timer在 watch 回调开头 clearTimeout }) return debouncedValue }严格来说上面的写法有 timer 清理问题。完整版本export function useDebounce(value, delay 300) { const debouncedValue ref(value.value) let timer null watch(value, (newValue) { if (timer) clearTimeout(timer) timer setTimeout(() { debouncedValue.value newValue }, delay) }) return debouncedValue }usePermission权限控制 Hook。根据当前用户权限判断按钮/路由是否可访问。useECharts封装 echarts 的初始化、resize、销毁以及配置项更新。这个是个大块头我单独写一篇文章都够了这里只提一下思路初始化图表实例监听容器尺寸变化自动 resize组件卸载时销毁实例配置项用watch驱动更新。这些 Hooks 单个看起来都不复杂但在项目里的聚合效果很惊人。团队里一旦形成了先看 Hooks 库再写页面的习惯新页面的开发速度会有明显提升。6. 我在自定义 Hooks 上踩过的坑每条都是真金白银6.1 别在 Hooks 里返回非响应式对象这个坑我踩得特别深。早期封装一个useTable时我的返回语句长这样return { list: list.value, // 错误 loading: loading.value, page: page.value }结果组件里list永远是初始值。原因很简单ref对象.value是一个普通值把它直接返回后续ref.value的更新无法传递到组件里。正确做法是返回 ref 本身return { list, // ref 对象 loading, // ref 对象 page // ref 对象 }如果你是给普通 JS 调用方用的可以返回readonly包装readonly(list)。这样能防止外部直接改状态统一通过 Hooks 暴露的方法更新。但在 Vue 组件模板里ref对象会自动解包直接返回list完全没问题。还有一个反向操作如果你在 Hooks 内部reactive创建了一个对象返回时直接返回reactive对象本身而不是toRefs展开后的某个单一属性。因为展开后实际上返回的是普通值同样会丢失响应式。6.2 watch 的清理组件卸载后仍在执行这个问题通常发生在异步请求的场景里。留意一下这个代码watch(keyword, async (newVal) { const res await fetchList({ keyword: newVal }) list.value res })组件卸载后如果keyword变化仍然触发这个 watch 回调而且请求恰好返回了就会给一个已卸载组件的状态赋值。常见后果是内存泄漏最直接的表现是控制台出现 Failed to execute removeChild on Node 之类报错。正确做法是在组件卸载时清理副作用import { watch, onUnmounted } from vue const stopWatch watch(keyword, async (newVal) { const res await fetchList({ keyword: newVal }) list.value res }) onUnmounted(() { stopWatch() })你可能觉得组件都卸载了谁还会改keyword但在真实项目里路由切换、跨页面状态管理、被 keep-alive 缓存后重新激活都会触发这类问题。尤其是如果 watch 的源是一个全局状态组件卸载后全局状态一变化watch 依然会执行。这是很隐蔽的坑排查时需要格外留意。6.3 过度抽象Hooks 滥用反而降低可维护性自定义 Hooks 不是写得越通用越好。我见过的最夸张的情况是一个useTable的配置项多到十几个每个页面调用时传一堆回调函数最后代码的可读性比直接写还差。我的经验是Hooks 的抽象层级要和业务复杂度匹配。如果只有一两个页面用直接写业务逻辑不需要抽 Hooks。如果三四个页面用了而且逻辑相同抽出来能明显减少样板代码可以做。如果一个 Hooks 的配置项超过五六个考虑拆分为更小粒度的 Hooks 组合而不是把全部场景塞进一个大 Hooks 里。比如useTable的基础版本只需要api和initialQuery两个参数。当某个页面需要多选行、树形表格、行内编辑这种特殊能力时用组合而不是加参数的方式扩展// 独立的多选 Hooks需要时再组合进来 export function useSelection() { const selectedRows ref([]) function handleSelectionChange(rows) { selectedRows.value rows } return { selectedRows, handleSelectionChange } }// 在组件里组合使用 const { list, loading, page, ... } useTable(config) const { selectedRows, handleSelectionChange } useSelection()这样比给useTable加一个enableSelection选项清晰得多也不会污染其他没有多选需求的页面。6.4 命名与语义的自我约束自定义 Hooks 的命名看起来是小问题但在团队协作里非常影响使用体验。我归纳了三条约束坚持下来收益很大第一必须以use开头。这是组合式 API 的社区约定。如果你的 Hooks 不以use开头别的开发者在搜索时很难判断哪些函数是组件逻辑、哪些是纯工具函数。也用不上 IDE 的自动补全提示。第二返回值必须有明确语义。尽量返回一个对象而不是数组。对象的好处是调用方能按需解构不受顺序影响。数组解构虽然灵活但几个值之间如果没有强顺序语义很容易写错位置。第三一个 Hooks 只做一件事。如果一个 Hooks 同时管理了useTable和useForm的逻辑请拆开。因为它们的复用场景不同——有的页面只有表格没有表单有的只有表单没有表格。混在一起会让两个场景都别扭。6.5 关于 vue3 用 ts 还是 js 的一个建议热词里有人问 vue3 用 ts 好还是 js 好我结合 Hooks 开发的体会说两句。如果你主要在写业务页面js 确实上手更快但一旦开始封装 Hooks泛型带来的类型推导优势会非常明显。上面的useTableT、useRequestT, P如果把泛型去掉调用方拿到的data是any编辑器给不了任何提示很容易写错字段名。所以我的建议是如果你打算认真做 Hooks 复用用 TypeScript。类型不光是给编译器看的更是给下一个接手你代码的同事看的。7. 把 Hooks 落地到团队从一个人的习惯到一套约定7.1 先找落地场景不要全面铺开自定义 Hooks 这件事最难的不是写而是让团队养成先找 Hooks 再写页面的习惯。我的经验是不要搞全员统一切换到 Hooks这种大动作而是先选一两个高频场景做样板。后台管理系统里最高频的场景就是表格页。花两周时间把useTable、useRequest、useSelection这几个基础 Hooks 沉淀出来选一个典型页面做完整改造。然后把改造前后的代码放在团队分享会上对比让大家直观感受少写了几十行样板代码是种什么体验。7.2 沉淀 Hooks 库但要克制当 Hooks 数量多了以后可以在项目里建src/hooks目录。按功能拆分文件src/hooks/ ├── useTable.ts ├── useRequest.ts ├── useSelection.ts ├── useDebounce.ts ├── useEventListener.ts ├── useLocalStorage.ts ├── usePermission.ts └── useECharts.ts但要注意每个 Hooks 都要有明确的适用场景和使用示例。我在项目里定的规矩是Hooks 文档必须写清楚解决的问题、参数说明、返回值说明、和一个最小示例。写不出来的不建议放进去宁可放在临时目录里验证一段时间。7.3 为什么我仍然建议团队从自定义 Hooks 开始而不是直接上状态管理库最后说一个团队协作中经常被问到的问题都用 Hooks 了还需要 Vuex / Pinia 吗我的看法是它们解决的不是同一类问题。Pinia 适合管理跨组件的全局状态比如用户信息、权限列表、主题配置。自定义 Hooks 适合管理组件内部的复杂逻辑尤其是那些只和当前页面相关、却需要复用同一套逻辑的场景。在实践中我和团队的协作习惯是先判断这个状态是页面级还是全局级。页面级的用 Hooks 封装全局级的放 Pinia 管理。这个边界划清楚之后状态管理从来不会打架Hooks 库也越来越厚维护成本反而下来了。8. 趁手的调试方式与小技巧开发 Hooks 期间有一些小技巧能明显提升效率。最后一个部分顺手分享一下。技巧一用unref兼容 ref 和普通值写 Hooks 时尽量让参数既支持 ref 也支持普通值。Vue3 里unref就是干这件事的import { unref } from vue function useNumber(value: number | Refnumber) { const num unref(value) // 如果是 ref 就取 .value否则直接返回 }这样调用方传ref(5)也行传5也行。很多高级 Hooks 的 API 设计都用了这个模式。技巧二在 template 里直接调试 Hooks 返回值开发时如果想知道某个 Hooks 返回了哪些字段可以在模板里临时加一段pre{{ JSON.stringify(useTable(...), null, 2) }}/pre不过在 script setup 里不能这样直接用普通组件的 setup 里可以。更简单的做法是直接在onMounted里console.log。技巧三用 Vite 的 alias 缩短导入路径项目里用 Vite 的话强烈建议配一个指向src这样导入 Hooks 的路径就非常简洁import { useTable } from /hooks/useTable这个小配置能极大提升日常开发中的幸福感尤其是 Hooks 嵌套组合的时候路径短一点点写起来都顺手得多。回到开头那个复制粘贴了五遍的项目。重构之后我们把所有列表页都改用useTable新增页面时只写接口定义和列配置几百行的组件缩到了几十行改接口字段只需要改一个地方。团队里新来的同学第一次看useTable的时候还有点懵我跟他讲了一句以后写页面别急着复制先想想这个逻辑是不是已经有人封装过了。这大概就是自定义 Hooks 最有价值的时刻——它让复用不再靠记忆和搜索而是靠一套抽象好的 API 约定。如果你正在负责一个中后台项目不妨找一个高频页面从抽一个最小的useTable开始试试。

Vue3自定义Hooks实战：从useTable到useRequest的封装与复用

相关推荐

RBAC前端架构之Layout布局：从页面骨架到动态权限体系

在 GitHub Actions 中集成 minikube 作为 CI 步骤：从集群启动到镜像构建与部署验证

SSM+Vue实现军队任务管理系统：从设计到答辩全流程

更多资讯

多模态不是智能核心：推理架构才是关键

DeepSeek V3.2-Exp 调用报 401？把 Codex 的 Base URL 填到 TaoToken 通道再试

Java户外用品销售网站设计与实现：从代码到论文答辩全攻略

Altium Designer 25 安装与工程标准化实战指南

机器学习指纹识别：从嵌入特征到TAR/FAR评估的工程实践

ERP选型实战指南：从业务场景反推技术能力

今日更新

校园网认证计费模式详解：AAA与代拨架构、原理及排障

Spring Boot+Vue垃圾分类毕设：分层、权限与排错实战

把 Cline 的 Base URL 改到 TaoToken 之后，DeepSeek 仍能修调试配置

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？