React脚手架与Hooks实战：从工程化配置到高复用封装

React脚手架及Hooks钩子，这两块东西在圈子里聊的人很多，但大多数讨论都停在了“脚手架怎么搭、Hooks怎么用”的演示层面，真正拿到生产环境、放进团队协作里，你会发现差得不是一星半点。我这篇是这个系列的第三篇，前两篇分别聊了整体技术选型和组件库设计，这一篇就把重点落在脚手架的配置细节和一批经过生产环境验证的Hooks封装上。如果你是准备在团队内做工程化标准化的前端负责人，或者独立开发想搭一套高质量项目底座，又或者正在刷React面试题、想系统梳理脚手架和Hooks的知识点，这篇应该能给你一些参考。

先说清楚这篇讲的是什么以及能解决什么问题。脚手架不是简单跑个create-vite就完事了，它背后是目录规范、代码规范、构建优化、环境治理这一整套约定；Hooks也不是把逻辑塞进useEffect里就叫封装，它涉及状态管理、副作用清理、竞态处理、内存泄露这些非常具体的问题。这篇会把我实际项目中沉淀下来的配置方案和Hooks设计思路完整展开，包括为什么这样配、为什么这样写、哪些地方容易翻车，希望对你有用。

1. 项目整体设计与技术选型

1.1 这套脚手架要解决的实际问题

先说背景。我当时接手团队前端基础建设时，仓库里躺着二十多个前端项目，技术栈五花八门：有用老版本React的、有用Vue的、还有纯jQuery的。新项目启动靠什么？靠从隔壁项目文件夹复制。复制完了要改半天——删掉无关页面、改路由、改包名、改axios封装，一个项目初始化少说要折腾一两天，初始化完了各种配置还不统一。

这个脚手架要解决的核心问题就是这些：

• 项目启动成本：从0到1跑起来一个可开发的项目，时间应该控制在分钟级，而不是半天。
• 一致性维护：所有项目共用同一套构建配置、代码规范、目录约定，人员流动和项目交接的成本能降下来。
• 公共能力沉淀：登录鉴权、请求封装、埋点上报、错误监控这些每个项目都要做的事，不应该每个项目重新写一遍。

这三点看着简单，真正做起来涉及的东西非常多。脚手架这个名字听起来像只负责"初始化"，但实际上它决定了后续所有项目演进的边界——规范怎么定，直接影响团队协作是否顺畅、代码是否好维护。所以设计阶段就得把格局打开，不能只想着"能跑就行"。

1.2 技术选型：为什么是Vite + React + TypeScript

技术栈这块没有太多悬念：React + TypeScript是当时团队的主流组合，需要讨论的主要是构建工具。Vite当时已经过了快速迭代期，生态也起来了，相比Webpack最大的优势是开发体验——依赖预构建加原生ESM，冷启动基本秒开，HMR也是毫秒级热更新。而且Vite对现代浏览器支持好，兼容性要求可以靠@vitejs/plugin-legacy兜底。

选Vite还有一个现实考量：团队的旧项目用的Webpack,很多历史包袱已经很难维护了。新项目如果继续用Webpack，等于保留了旧问题；全部迁移又不现实。Vite的好处是可以作为"新项目专用配置"，和旧项目并行存在，慢慢引导团队往新方向走。真遇到复杂的多页面或者特定需求，Vite也支持输出Webpack配置的兼容方案，不至于把路堵死。

TypeScript这块，我直接开了strict模式，这点后面细说。简单说就是：团队协作里，类型系统是最便宜的沟通文档，严格模式虽然最开始会让一些人难受，但后续维护省下的时间远超那几天适应期。

公共依赖方面，这套脚手架预装了这些核心包，并给出了替代选择：

1.3 目录结构与约定的建立

脚手架除了配置，更重要的是目录约定。我把目录结构设计成下面这样，并且让CLI初始化时直接生成这个骨架：

project-root ├── src │ ├── api # 接口定义与请求封装 │ ├── assets # 静态资源 │ ├── components # 通用组件 │ ├── hooks # 自定义Hooks │ ├── layouts # 布局组件 │ ├── pages # 路由页面 │ ├── stores # 全局状态 │ ├── utils # 工具函数 │ ├── App.tsx │ └── main.tsx ├── .env.development ├── .env.production ├── vite.config.ts └── tsconfig.json

目录划分乍一看没什么新意，但关键在于我加了三条硬性约定：hooks只放与业务无关的通用逻辑，页面相关的状态不要塞进stores目录，utils里不允许出现any。这三点是很多项目后期腐烂的根源——文件夹谁都会建，守住边界才是真本事。我在脚手架里把ESLint规则和目录约定绑到了一起，比如在api目录里限制直接使用axios实例、在hooks目录里不允许出现window全局操作等，从工具层面约束行为。

2. 脚手架核心配置解析

2.1 项目模板与CLI设计

脚手架的核心不只是配置本身，而是"如何把这些配置快速落到新项目里"。我这里做了一个简单的CLI工具，核心命令就三条：

# 创建新项目 create-app init project-name # 添加一个新页面（自动生成路由和目录） create-app add:page dashboard # 查看脚手架版本和更新日志 create-app info

CLI本身不复杂，本质上是把模板目录复制过去，然后根据用户输入替换项目名、包名等占位符。但add:page这个命令非常实用，它自动完成了几件事：读取当前项目的路由配置文件、生成页面目录和入口文件、把新路由追加到配置里。这避免了团队里有人复制粘贴写路由时漏掉导入语句的问题，也让页面结构保持一致。

命令实现基于Node.js脚本，模板目录用统一的变量占位符，比如{{projectName}}、{{npmName}}，复制后统一替换。CLI的代码不需要做得太重，因为脚手架最大的价值是沉淀约定，而不是成为一个复杂的工具。

2.2 Vite配置的关键参数

vite.config.ts是脚手架的心脏。我把几个关键配置展开说一下。首先是路径别名：

// vite.config.ts import { fileURLToPath, URL } from 'node:url' import { defineConfig } from 'vite' export default defineConfig({ resolve: { alias: { '@': fileURLToPath(new URL('./src', import.meta.url)), }, }, })

路径别名的价值不只是少敲几个../../，它更重要的是让代码的“物理结构”变得清晰——@/api、@/components、@/hooks一在import里出现，别人就能快速感知代码归属哪个层。但这里有个坑：如果你只在vite.config里配了alias而tsconfig里没有同步配置，编辑器会报红，类型检查也会挂。所以脚手架里tsconfig.json的paths字段必须同步：

{ "compilerOptions": { "baseUrl": ".", "paths": { "@/*": ["src/*"] } } }

开发代理的配置也值得多说两句。本地开发永远会遇到接口跨域问题，与其让后端配CORS，不如在前端做个代理。Vite的server.proxy很灵活，我直接按环境变量去区分代理目标：

// vite.config.ts export default defineConfig({ server: { proxy: { '/api': { target: process.env.VITE_PROXY_TARGET || 'http://localhost:8080', changeOrigin: true, ws: true, }, }, }, })

这里有一个实际经验：changeOrigin一定要设为true，否则部分后端服务在校验Host头的时候会直接拒绝请求。另外，ws: true是给WebSocket代理用的，很多实时功能开发时都靠它。

构建配置这块，最值得花心思的不是代码压缩，而是拆包策略。默认情况下Vite会把所有依赖打进一个Chunk，首屏加载会很慢。我用了manualChunks把体积较大的依赖独立分包：

// vite.config.ts export default defineConfig({ build: { rollupOptions: { output: { manualChunks(id) { if (id.includes('node_modules')) { if (id.includes('react') || id.includes('react-dom')) { return 'react-vendor' } if (id.includes('lodash') || id.includes('ramda')) { return 'util-vendor' } if (id.includes('antd') || id.includes('@arco-design')) { return 'ui-vendor' } } }, }, }, }, })

拆包之后还需要配合chunkSizeWarningLimit把警告阈值调高一点，不然每次构建都在控制台刷一堆体积警告，容易让人麻木，反而掩盖了真正需要关注的体积问题。

2.3 TypeScript与代码规范配置

TypeScript的strict模式我在前面提了，这里具体说说为什么这么坚持。strict模式包含noImplicitAny、strictNullChecks、noUncheckedIndexedAccess等一整套严格检查。在团队协作场景里，它相当于一个自动的代码审查员——把一个可能的运行时错误在编译期就拦下来。

不过严格模式最大的阻力来自老项目习惯：很多人在Vue或JS时代习惯了"先写任何类型,后面再修",迁到严格模式会觉得写代码变慢了很多。我的解法是：在脚手架模板里把类型定义的各种写法都示范了一遍，尤其是接口、泛型、类型守卫这些高频场景。新人打开仓库照着示例写，基本不会遇到“不知道类型该怎么写”的尴尬。

ESLint和Prettier的配置在脚手架里也有讲究。我的原则是：代码风格全部交给Prettier,ESLint只关注"代码质量"而非"代码风格"。所以ESLint规则里我没有开quotes、semi这类风格规则，只保留了no-unused-vars、@typescript-eslint/no-explicit-any这类实质性问题检查。这样做的好处是编辑器格式化后的代码和CI检查的预期完全一致，不会出现“本地改的好好的，push上去CI就挂”的情况。

2.4 为什么“约定优于配置”

脚手架做到这里，其实最核心的设计哲学就四个字：约定优于配置。这句话听起来很虚，落地到我这个项目里就是几条具体的决策：

• 所有请求模块必须放在src/api目录，并且按领域模块拆文件。
• 所有页面组件必须放在src/pages目录，文件名和路由路径保持对应。
• 所有全局状态必须通过zustand的create创建并放在src/stores目录。
• 组件内部状态能用useState就不用全局store，避免状态膨胀。

这些约定不是技术限制，而是治理策略。因为当团队规模变大之后，最大的成本不是写代码，而是理解代码。如果每个项目的目录结构都不一样，新人光看目录就要花好几天。约定统一之后，一个人能同时维护多个项目，因为他知道每个项目里什么东西应该放在哪里、出问题应该先查哪里。

3. Hooks 钩子的实战封装

3.1 通用思维：Hooks封装的第一原则

Hooks封装这件事，第一原则是"为场景设计，不为抽象设计"。意思是说，不要想着写一个万能Hooks去覆盖所有需求，而要先收集真实业务场景，针对高频场景设计接口。很多Hooks写得难用，就是因为作者把太多不相关的能力揉在一起，参数列表一大串，没人看得懂。

我的设计思路是：每个Hooks只解决一类核心问题，对外暴露尽量少的参数，内部处理尽量多的复杂度。比如请求Hooks，调用者只需要告诉我“请求方法”和“参数”，剩下的缓存、竞态、取消、错误处理都在内部完成。

3.2 数据请求Hooks：useRequest

数据请求是React应用里最常见的业务逻辑。直接在每个组件里写useEffect + axios会有几个问题：竞态条件、重复请求、加载状态管理混乱。我封装了一个useRequest，核心代码如下：

import { useCallback, useEffect, useRef, useState } from 'react' interface RequestOptions { manual?: boolean defaultParams?: any onSuccess?: (data: any) => void onError?: (error: any) => void } function useRequest<T>(service: (params?: any) => Promise<T>, options: RequestOptions = {}) { const { manual = false, defaultParams, onSuccess, onError } = options const [data, setData] = useState<T>() const [loading, setLoading] = useState(false) const [error, setError] = useState<Error>() const requestIdRef = useRef(0) const run = useCallback(async (params?: any) => { const currentId = ++requestIdRef.current setLoading(true) setError(undefined) try { const result = await service(params ?? defaultParams) if (currentId === requestIdRef.current) { setData(result) onSuccess?.(result) } } catch (e) { if (currentId === requestIdRef.current) { setError(e as Error) onError?.(e) } } finally { if (currentId === requestIdRef.current) { setLoading(false) } } }, [service, defaultParams, onSuccess, onError]) useEffect(() => { if (!manual) { run(defaultParams) } }, [manual, run, defaultParams]) return { data, loading, error, run } }

这个Hooks最关键的设计是requestIdRef。每次发起新请求时递增一个ID，只有最后一次请求的返回结果才会被真正更新到状态里。这就避免了经典竞态问题——比如搜索框里输入关键字，前一个请求比后一个慢，回来时把后一个请求的结果覆盖了。没有这个处理，生产环境里会出现很诡异的数据错乱问题。

实际使用的时候，我并不希望每个组件都自己去调用useRequest，而是配合具体的接口封装使用。比如：

// src/api/user.ts import { useRequest } from '@/hooks/useRequest' export function useUserInfo(params?: { id: string }) { return useRequest((p) => api.getUserInfo(p ?? params), { defaultParams: params }) }

这样组件里只需要const { data, loading } = useUserInfo({ id: '123' })就可以了，接口定义和页面调用天然分离，类型也能自动推导，这就把Hooks和数据层之间的边界理清了。

3.3 实时通信Hooks：useWebSocket与useSSE

WebSocket是实时通信场景绕不开的东西，但原生WebSocket的API用起来有点繁琐，还要处理异常重连、心跳保活这些细节。我在脚手架里封装了useWebSocket，核心解决三个问题：连接管理、自动重连、消息收发。

import { useEffect, useRef, useState } from 'react' interface WebSocketOptions { url: string onMessage?: (data: any) => void reconnectLimit?: number heartbeatInterval?: number } function useWebSocket(options: WebSocketOptions) { const { url, onMessage, reconnectLimit = 5, heartbeatInterval = 30 * 1000 } = options const wsRef = useRef<WebSocket>() const reconnectCountRef = useRef(0) const [connected, setConnected] = useState(false) const connect = () => { const ws = new WebSocket(url) wsRef.current = ws ws.onopen = () => { setConnected(true) reconnectCountRef.current = 0 } ws.onmessage = (event) => { const data = JSON.parse(event.data) onMessage?.(data) } ws.onclose = () => { setConnected(false) if (reconnectCountRef.current < reconnectLimit) { reconnectCountRef.current += 1 setTimeout(connect, 1000 * reconnectCountRef.current) } } ws.onerror = () => ws.close() } useEffect(() => { connect() const heartbeat = setInterval(() => { if (wsRef.current?.readyState === WebSocket.OPEN) { wsRef.current.send(JSON.stringify({ type: 'ping' })) } }, heartbeatInterval) return () => { clearInterval(heartbeat) wsRef.current?.close() } }, [url]) const send = (data: any) => { if (wsRef.current?.readyState === WebSocket.OPEN) { wsRef.current.send(JSON.stringify(data)) } } return { connected, send } }

这里的几个细节值得注意。reconnectLimit要配上，不然网络抖动会导致无限重连，服务端压力大，前端也白白耗电。重连间隔用退避策略（每次重连间隔乘2），避免服务端恢复后一瞬间涌进大量重连请求。心跳消息是写死{ type: 'ping' }的，实际业务里可以按后端协议调整，但原理一样——通过周期性发送小消息来感知连接是否还活着。另外，组件卸载时必须close()连接并清掉心跳定时器，否则连接会一直挂着，服务端资源泄漏很头疼。

SSE这边的封装思路类似，区别在于SSE是单向的（服务端推送），不需要发送消息，而且用EventSource实现。我封装的useSSE连接了error事件并自动重连，这里有一个注意点：EventSource默认会把消息解析成event.data，如果服务端返回的是JSON字符串，记得在onmessage里JSON.parse一次。很多人在SSE上翻车就是因为忘了这一步，拿到字符串就渲染，页面上直接显示[object Object]。

3.4 组件状态与副作用Hooks：useInterval、useEventListener

除了请求和通信，侧向的副作用Hooks也很常用。我写了一套小而精的：

useInterval解决的是"在React里用setInterval容易踩闭包坑"的问题。直接写setInterval，回调里引用外部变量时很容易拿到旧值，因为回调函数捕获的是第一次渲染时的闭包。我的实现是在每次渲染时把回调保存到ref里，interval只负责调用最新的ref：

import { useEffect, useRef } from 'react' function useInterval(callback: () => void, delay: number | null) { const savedCallbackRef = useRef(callback) useEffect(() => { savedCallbackRef.current = callback }, [callback]) useEffect(() => { if (delay === null) return const id = setInterval(() => savedCallbackRef.current(), delay) return () => clearInterval(id) }, [delay]) }

这个模式其实就是"ref保存最新值"的经典用法，可以推广到所有定时器、事件监听场景里。useEventListener同理，把原生监听器的绑定和解绑做成了声明式API，并且自动处理window、document等目标元素：

function useEventListener<K extends keyof WindowEventMap>( eventName: K, handler: (e: WindowEventMap[K]) => void, element: EventTarget = window, ) { const savedHandlerRef = useRef(handler) useEffect(() => { savedHandlerRef.current = handler }, [handler]) useEffect(() => { const eventListener = (e: Event) => savedHandlerRef.current(e) element.addEventListener(eventName, eventListener) return () => element.removeEventListener(eventName, eventListener) }, [eventName, element]) }

这些Hooks看起来简单，但在实际开发中节省的代码量非常可观，而且能避免大量低级bug——比如监听器没有清理导致的内存泄漏、事件回调里读到旧状态的诡异问题。

4. 真实场景落地

4.1 SSR数据预获取的预留方案

虽然这套脚手架初始是CSR的，但考虑到SEO和首屏性能，我在接口层设计上为SSR预留了空间。具体做法是在useRequest内部不做任何依赖window的全局操作，数据请求全部走可注入的fetcher——浏览器环境默认axios，服务端环境可以替换成node-fetch或axios的server适配。

SSR的数据预获取，核心问题是“在服务端提前拿到数据并注入到渲染结果中”。社区方案有react-query的prefetchQuery、Next.js的getServerSideProps。在我这个脚手架的语境下，预留方式是把数据请求从组件生命周期里抽出来，改为可调用的“预取函数”。比如：

// src/pages/dashboard/index.tsx export const preload = async () => { return { stats: await api.getDashboardStats(), } }

路由组件导出preload后，SSR框架可以在服务端调用它并把结果注入到window.__INITIAL_DATA__，客户端渲染时直接读取注入数据跳过请求。这样改造的代价很小，但为后续SSR升级留好了路。

这里想多说一句：SSR不是一个"加个插件"就完事的东西，它涉及组件生命周期、数据获取、样式注入、错误处理多个层面的改造。脚手架阶段做的不是把所有SSR能力都铺好，而是保证数据层不依赖客户端专属API，让后续接入时不至于推翻重来。

4.2 图表场景：uPlot K线图与Hooks化封装

热词里提到了uPlot和K线图，这块我确实在项目里实践过。uPlot是一个轻量级的高性能图表库，体积小、渲染快，特别适合K线这种需要高频更新的场景。但它API偏底层，使用门槛高，所以我封装了一个useKLineChart的Hook，把复杂的初始化、更新、销毁逻辑都收进去。

import { useEffect, useRef } from 'react' import uPlot from 'uplot' function useKLineChart(containerRef: React.RefObject<HTMLDivElement>, data: any) { const chartRef = useRef<uPlot>() useEffect(() => { if (!containerRef.current) return chartRef.current = new uPlot({ width: containerRef.current.clientWidth, height: 400, series: [ // K线图配置，开盘、收盘、最高、最低四个序列 ], }, data, containerRef.current) return () => { chartRef.current?.destroy() } }, []) useEffect(() => { chartRef.current?.setData(data) }, [data]) }

这个封装思路适用于所有“非React控制”的第三方库。核心就两点：初始化放在useEffect里并注册清理函数；数据更新通过另一个useEffect触发库实例的更新方法。这样图表实例的生命周期和组件完全同步，不会出现组件卸载了图表还在定时更新的内存泄漏。

踩过的坑有两个。一个是容器尺寸变化时图表不会自动重绘，需要在ResizeObserver里调用uPlot的setSize方法。另一个是数据更新频率很高时（比如实时K线），要注意setData的性能，必要时做一下数据降采样，不然再快的图库也扛不住无限制的数据流。

4.3 使用Hooks监听文件变化与轮询

文件变化监听这个场景通常出现在后台管理系统或者编辑器类项目里，比如上传目录后要实时刷新文件列表。实现方式可以用SSE或者WebSocket推送，也可以简单用轮询。在我的封装里，轮询场景统一用前面写的useInterval：

const { data: fileList, run: fetchFileList } = useRequest(fetchFileListApi) useInterval(() => { fetchFileList() }, isWatching ? 5000 : null)

注意这里useInterval的delay参数传null时自动停止轮询，这个设计非常灵活。如果你需要更实时的体验，就把SSE/WebSocket方案接进来，把推送事件当作“触发重新拉取”的信号，而不是依赖推送里的全量数据。这种“推送告知，拉取更新”的组合模式，比单纯推送或者单纯轮询都更可靠。

4.4 消息推送与协作场景：SSE/WebSocket在前端的落地

消息推送场景（比如项目里某个用户的操作通知其他协作者）我用useSSE和useWebSocket都实现过，简单对比一下两个方案的取舍：

实际项目里，我把SSE封装成了useSSE，把事件类型做成了可订阅模式，组件里这样用：

const { connected, events } = useSSE('/api/notifications') events.filter(e => e.type === 'file:change').subscribe((e) => { // 触发文件列表刷新 })

这里顺手踩过一个坑：很多后端对SSE连接的数量有限制，如果页面开多个SSE连接，连接数很快就满了。解决方案是让后端多路复用——一个连接上带多个事件类型，前端按type字段分发。后端的连接限制不归我管，但前端的Hooks封装必须支持这种多事件分发。

5. 常见问题与排查技巧实录

5.1 脚手架初始化中容易踩的坑

脚手架本身也是一段代码，用久了总会在各种环境里出问题。我遇到过几个典型的情况：

Node版本不一致是最常见的。Vite对Node版本有要求，老版本Node装最新的Vite会直接报错甚至装不上依赖。解决之道是在脚手架模板里加了package.json的engines字段和.nvmrc文件：

{ "engines": { "node": ">=18.0.0" } }

# .nvmrc 18.18.0

这样团队里不管是nvm、fnm还是volta，都能自动切换到指定Node版本。没有这个，十个人开发就有十种Node环境，构建结果各不相同，排查问题会非常痛苦。

包管理器不一致也是个坑。有的团队成员用npm，有的用yarn，有的用pnpm。npm和yarn的node_modules结构不同，混用时会出现"我一个同事环境没问题，我这边就是跑不起来"的灵异事件。我在脚手架模板里加了packageManager字段锁死pnpm，并加了preinstall脚本做强制校验。

5.2 Hooks常见的闭包陷阱与StrictMode双调用

Hooks最经典的坑就是闭包陷阱。举一个最简单的例子：在useEffect里注册一个定时器，回调里读取某个state，你会发现读到的永远是初始值。原因就是effect的回调闭包捕获了第一次渲染时的state。我在useInterval和useEventListener里都用了ref保存最新回调，就是为了绕开这个问题。

React 18的StrictMode会让useEffect在开发环境跑两次，这个设计是为了帮你暴露副作用问题，但很多人没意识到这一点，导致Hooks里出现了“重复请求”“重复注册事件”的现象。我自己的排查经验是：如果开发环境里某个请求发了两遍，先别急着骂后端或者改StrictMode，先检查你的useEffect依赖数组是否正确、清理函数是否有效。StrictMode双调用是故意设计的，不是bug——真正有问题的代码会在双调用时暴露出来。

5.3 性能优化：useMemo/useCallback该不该滥用

面经里经常有人问useMemo和useCallback的用法，我的回答是：少用，但要用在刀刃上。useMemo和useCallback本身也有开销，它们依赖数组的比较也是需要计算的。如果每次渲染都要比较一个复杂的依赖对象，那这性能优化的意义就存疑了。

真正的使用场景是：子组件使用React.memo时，父组件传给它的函数或对象必须是稳定引用，否则memo就失效了。或者是在useEffect的依赖数组里引用了一个从props计算来的对象，为了防止无限循环，才需要用useMemo保持引用稳定。

我见过不少同学把useCallback加在每一个函数上，这就是典型的“为了优化而优化”。在脚手架项目的代码规范里我没有强制禁用，但代码审查时会重点提醒：先测量，再优化。否则你花一小时加的useMemo，可能只带来千分之一秒的收益。

5.4 面试知识点串联：从脚手架到Hooks的高频考点

这个系列的文章出来之后，不少读者反馈说对准备面试也有帮助，所以我把这道线再拉一下。前端面试里React相关的问题大概分这么几层：

基础层：虚拟DOM、diff算法、组件通信、生命周期（现在叫函数组件的副作用时机）。

Hooks层：useState/useEffect/useMemo/useRef的原理，自定义Hooks的执行顺序和闭包陷阱，为什么Hooks不能写在条件语句里（因为React按调用顺序维护Hook链表，条件执行会破坏顺序）。

工程层：脚手架配置、构建优化、Tree Shaking、代码分割、SSR/CSR区别、状态管理选型。

架构层：如果面试官问到“你会怎么设计一个团队的前端基建”，这时候回答的骨架就是脚手架目录规范 + Hooks复用 + 组件库设计 + CI/CD流程。这套内容我在这个系列的前两篇里都写过，第三篇把这几个部分拧到一起——脚手架本身是骨架，Hooks是关节，两者结合起来才是一个能支撑团队运转的完整体系。

以我个人的实际体感，做脚手架和Hooks封装最忌讳的就是“闭门造车想当然”。你设计了一个目录结构，但团队按习惯写了两天就发现别扭，那这个结构就得调整；你封装了一个Hooks，但第一个使用方反馈"这个接口不够灵活"，那就得重新思考抽象边界。我这套方案也是在真实项目里跑了几个月、按团队反馈迭代了好几版才稳定下来的。抽象程度要克制，Hooks不是越通用越好，脚手架也不是功能越多越好，以解决当前团队的实际问题为边界，把复杂留在内部、把简洁留给使用者，才是这套基建能持续用下去的关键。希望这篇能帮你少走一些弯路。