企业官网建设流程全解析

“rea”这个代号，我在接手的时候甚至以为是个拼写到一半的单词。直到看完需求文档才发现，它是一个内部管理系统的前端重构项目——老代码跑了四五年，业务越堆越多，组件烂成一锅粥，每次加需求都要在几百行的“面条组件”里翻来翻去。我这次要做的，就是基于这个代号为“rea”的项目，把技术栈、工程结构、核心模块的实现思路从头梳理一遍，顺带把踩过的坑也一并倒出来。这篇文章适合刚接触中后台项目重构的开发者，也适合那些想把项目从“能跑”提升到“好维护”的团队参考。

先说清楚这个项目要解决什么问题。旧系统的痛点其实很典型：没有统一的组件规范，同样的一个表格组件在不同页面里被复制粘贴了十几份，改一个字段要对所有副本动手；全局状态塞满了临时数据，页面刷新就丢，排查问题时根本不知道数据从哪儿来；接口层直接裸写在业务组件里，接口一变更，改动的文件能排成一列长队。所以“rea”这个项目本质上不是从零开始写一个系统，而是把旧的业务逻辑全部梳理清楚之后，在一个新的工程骨架上重新搭建一套可维护、可扩展的前端应用。

1. 项目整体设计与方案选型

1.1 核心需求与技术栈取舍

重构之前，我花了两天时间把老的代码库整个翻了一遍。这里想说的是，很多人一上来就急着删代码、换框架，其实是大忌。重构的第一步永远是梳理业务，把页面清单列出来，把共用的逻辑抽出来，把接口的依赖关系摸清楚。我当时的做法是拉了一个表格，每个页面一行，记录它用到的组件、状态、接口、路由，最后汇总出一张“依赖关系图”。做完这一步，技术方案的选型就顺畅多了。

“rea”这个项目最终选定的技术栈是 React 18 + TypeScript + Vite，状态管理用轻量的 zustand，接口层封装了 axios，UI 组件库选了 antd 的按需引入版本。选 React 而不是 Vue，并不是说 Vue 不好，而是团队里现有的代码和团队成员的技能栈更偏 React，而且旧系统本身就是 React 写的，迁移成本最低。TypeScript 是必须的，中后台项目的业务复杂度决定了纯 JavaScript 撑不住——特别是接口返回的数据结构五花八门，有了类型定义才能在上层安心使用。

选 Vite 取代 webpack，最直接的理由就是快。旧项目用 webpack 的时候热更新经常要等好几秒，改一个样式文件甚至要重新编译整站依赖，开发体验非常糟糕。Vite 基于 esbuild 预构建依赖，开发服务器启动基本在 1 秒以内，热更新是毫秒级的。对于“rea”这种几百个组件的中大型项目，节省的开发时间相当可观。

状态管理我只选了 zustand。对比 Redux 全家桶，zustand 的 API 极其精简，没有 Provider 包裹的繁琐，也不用手写一堆 action creator、reducer 模板代码。它的核心原理是基于 hook 的订阅机制，组件只在用到某个状态切片时才触发重渲染。对于“rea”这种以服务端数据为主、共享状态不多的应用，完全够用。如果你习惯 Redux，迁移到 zustand 几乎零成本，底层思想都是“单一状态源 + 派发更新”，只是 zustand 帮你省掉了大量仪式代码。

1.2 整体项目结构设计

项目结构直接决定了后续开发的效率。“rea”落地之初我把目录划分得比较细，参考的是行业里常见的 feature-based 结构，而不是简单的按类型堆文件。核心是让每个业务模块自成一体，模块内部再拆分组件、状态、接口和类型。

src/ ├── api/ # 接口请求层 ├── assets/ # 静态资源 ├── components/ # 公共组件 ├── config/ # 全局配置 ├── hooks/ # 自定义 Hook ├── layouts/ # 布局组件 ├── pages/ # 页面入口 ├── router/ # 路由配置 ├── stores/ # 状态管理 ├── styles/ # 全局样式 ├── types/ # 类型定义 └── utils/ # 工具函数

需要注意的是，只靠这层目录还不够，真正的业务模块是藏在pages里的。比如“用户管理”这个模块，我会在pages/UserManagement下面继续建components、hooks、api、types子目录，模块内部的私有组件和逻辑不会外泄到全局的components中去。全局的components只放那种真正跨模块的通用组件，比如上传组件、富文本编辑器、自定义弹窗。

分层的思想用一个生活类比来说就是：全局components是公共设施，如水电气管道；每个业务模块是独立的房间，房间内部的电路不再需要穿过整栋楼。规划好这个骨架，后续的代码才不会散落一地。

2. 核心细节解析与关键环节实操

2.1 接口层设计与请求封装

“rea”项目里对 axios 做了一层很薄的自定义封装，而不是直接在业务里调用 axios 实例。这么做的原因有两个：一是统一处理错误码和 token 过期问题，二是方便在请求前后做数据格式化、埋点等横切逻辑。

封装的核心代码如下（简化版）：

import axios from 'axios'; const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL, timeout: 15000, }); service.interceptors.request.use((config) => { const token = localStorage.getItem('token'); if (token) config.headers.Authorization = `Bearer ${token}`; return config; }); service.interceptors.response.use( (response) => response.data, (error) => { if (error.response?.status === 401) { // 跳转登录页并清理缓存 window.location.href = '/login'; } return Promise.reject(error); } ); export default service;

这里有几个细节值得注意。响应拦截器直接返回了response.data，业务层拿到的就是解析后的数据，而不是 axios 包装过的完整响应对象。这样约定之后，接口层的调用就非常清爽。另外，后端的接口设计遵循的是一个统一的返回格式：{ code, data, message }。我建议在封装层加一个对code的判断，非零直接抛出带message的错误，而不是让每个业务页面自己判断。

对于“rea”这种中后台项目，接口路径建议也集中管理。我在api目录下按业务模块建了多个文件，比如userApi.ts、orderApi.ts，每个文件导出对应的请求函数，命名方式统一为action + Module + Method。比如fetchUserList、deleteOrderById。这样一来，全局搜接口函数名就能定位到所有调用点，比起在业务代码里写死字符串质的提升。

2.2 路由与权限模型

权限是中后台项目里绕不开的环节。“rea”的权限模型并不是简单地用“管理员/普通用户”这种硬编码角色，而是采用“路由配置 + 权限码校验”的方案。

路由表里的每一项都带一个permissionCode字段，比如：

const routes = [ { path: '/dashboard', component: Dashboard, permissionCode: 'dashboard:view', }, { path: '/user', component: UserManagement, permissionCode: 'user:manage', }, ];

在生成路由对象前，我会拿到当前用户的权限码列表（由后端登录接口返回），然后用一个filterRoutesByPermission函数动态过滤。过滤之后的真实路由表再传给 React Router。页面注册好了还不够，按钮级别的权限也要处理——比如一个“删除”按钮不是所有有页面权限的人都能用。这里我写了一个自定义 hookusePermission，它接收权限码，返回一个布尔值，组件内根据布尔值来决定是否渲染按钮。

function usePermission(code: string) { const codes = useAuthStore((state) => state.permissionCodes); return codes.includes(code); }

这套方案的核心好处是权限逻辑集中、不散落在模板判断里。坏处也明显——权限码的命名必须和后端统一，沟通成本比较高。项目初期我们前后端一起开会定了权限码的格式规范，后续基本没出过扯皮的事。

2.3 状态管理实践

“rea”的状态按生命周期分成三类：临时 UI 状态、页面共享状态、全局登录状态。这三类用的工具和写法完全不同。

临时 UI 状态，比如弹窗开合、表单折叠、Tab 切换，这些用组件自身的useState就够了，完全不需要放入全局 store。放进去反而是污染，刷新页面就丢，每次还要做初始化，纯属给自己找麻烦。

页面共享状态，比如“订单列表”页的筛选条件需要被列表组件、分页组件、导出组件共用，这种我会用 zustand 建一个页面级的 store。以订单页为例：

interface OrderState { filters: OrderFilter; page: number; pageSize: number; setFilters: (filters: OrderFilter) => void; setPage: (page: number) => void; } export const useOrderStore = create<OrderState>((set) => ({ filters: { status: 'all', keyword: '' }, page: 1, pageSize: 20, setFilters: (filters) => set({ filters, page: 1 }), setPage: (page) => set({ page }), }));

全局登录状态，包含用户信息、token、权限码列表，这个所有页面都可能用到，放在一个useAuthStore中。特别注意一点：token 不仅要存在内存的 store 中，还要同步到 localStorage，否则刷新页面后 store 内容会清空。初始化时可以写一个initAuthFromStorage函数，在应用入口处调用一次。

提示：zustand 的create方法默认返回的是一个 hook，在非组件环境下（比如 axios 拦截器）拿状态要用useAuthStore.getState()，不能用 hook 调用。这是新手最容易踩的坑，也是我在代码评审里经常看到的低级错误。

2.4 公共组件封装方法论

“rea”项目里的公共组件不是一开始就规划好的，而是在开发过程中不断从业务代码中提炼出来的。原则很简单：同一个业务组件在三个及以上页面出现，且交互逻辑一致，就抽取到全局components。

举个例子，系统里几乎每个列表页都要用到一个“搜索条件 + 表格 + 分页”的组合，我把这套组合封装成了QueryTable组件。它接收一个配置对象，描述筛选表单有哪些字段、表格有哪些列、请求函数是什么，然后内部自动完成数据请求、表单校验、查询重置、分页联动等逻辑。

封装之后的业务代码非常简洁：

const columns = [ { title: '订单号', dataIndex: 'orderNo' }, { title: '金额', dataIndex: 'amount' }, ]; const searchFields = [ { name: 'orderNo', label: '订单号', type: 'input' }, { name: 'status', label: '状态', type: 'select', options: statusOptions }, ]; <QueryTable columns={columns} searchFields={searchFields} request={fetchOrderList} />

当然，过度封装也是一种灾难。如果一个组件的配置项超过二十个，且内部逻辑分支复杂，那它的维护成本甚至比业务代码还高。我的判断标准是：配置化程度以“能覆盖多数页面需求，少数页面必要时可以直接绕过封装用原生写法”为上限。保留逃生门很重要。

3. 实操过程与关键模块实现

3.1 从零搭建工程骨架

“rea”项目的工程搭建没有用脚手架的全量模板，而是手动按需生成的。原因很简单：全量模板往往带了用不上的东西，比如 SEO 相关配置、PWA 支持，对于纯后台应用来说这些只会增加理解成本。我选择用 Vite 的create-vite创建基础的空模板，然后把 TypeScript、ESLint、Prettier、路径别名、环境变量这些基础配置一个一个加进去。

一个比较实用的配置是路径别名。我在vite.config.ts里配置@指向src目录，同时记得在tsconfig.json的compilerOptions里同步加上baseUrl和paths，否则编辑器会飘红，构建时也会报错。

// vite.config.ts resolve: { alias: { '@': path.resolve(__dirname, 'src'), }, }

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

这个细节看起来不起眼，实际开发中每天都要用，配置错了会严重拖慢开发节奏。我自己有段时间只配了 Vite 的 alias，忘了改 tsconfig，编辑器里所有带@的 import 都标红，排查了半小时才发现是两边没同步。

工程的代码规范我直接用了社区里比较成熟的方案：ESLint 采用 TypeScript 推荐的规则集，Prettier 统一代码风格。为了减少争议，提交前统一用lint-staged+husky跑一遍检查和格式化，不符合规范的一律进不了代码库。

3.2 列表页与筛选联动的完整实现

列表页是中后台项目出现频率最高的页面类型。以“订单列表”为例，完整实现涉及搜索表单、数据表格、分页器、loading 态、空态、错误态这六块内容。我封装了一个usePageDatahook 来统一管理这套逻辑，业务组件只需要给它传入请求函数和筛选参数生成函数。

function usePageData<T>( fetcher: (params: any) => Promise<ListResult<T>>, deps: any[] ) { const [data, setData] = useState<T[]>([]); const [loading, setLoading] = useState(false); const [pagination, setPagination] = useState({ page: 1, pageSize: 20, total: 0 }); const [filters, setFilters] = useState({}); const loadData = useCallback(async () => { setLoading(true); try { const result = await fetcher({ ...filters, page: pagination.page, pageSize: pagination.pageSize }); setData(result.list); setPagination((prev) => ({ ...prev, total: result.total })); } finally { setLoading(false); } }, [filters, pagination.page, pagination.pageSize, deps]); useEffect(() => { loadData(); }, [loadData]); return { data, loading, pagination, filters, setFilters, setPagination, reload: loadData }; }

这里有几个关键点要用脑子记。一是filters变化后要把页码重置为 1，否则会出现“当前在第 5 页，切换筛选条件后没有数据”的尴尬情况。二是fetch请求要加防抖吗？不加。页面的筛选操作是用户主动点击查询或重置，不是输入过程中实时请求。但搜索输入框本身有 onPress Enter 触发查询，我用了 lodash 的debounce来防止连续回车。

表格的列配置里还隐藏着不少细节。比如金额字段，后端返回的是以“分”为单位的整数，要在render函数里转成元并保留两位小数；比如状态字段，要映射成对应的 Tag 颜色；比如操作列的按钮权限，必须用usePermission校验。

3.3 复杂表单页的处理方案

表单页是另一个重头戏。“rea”里有一个比较复杂的表单：新建一件商品，涉及基础信息、规格、价格库存、上传图片、是否上架等二十多个字段。直接用一个巨型Form组件处理，代码会非常臃肿。

我的方案是把表单拆成了多个子组件，每个子组件负责一个区块，但所有字段统一注册到父级的Form实例中。这样既保证了一致的校验和提交逻辑，又避免了单个组件过长。

function ProductForm() { const [form] = Form.useForm(); const handleSubmit = async () => { const values = await form.validateFields(); await createProduct(values); }; return ( <Form form={form} onFinish={handleSubmit}> <BasicInfoSection /> <SpecSection /> <PriceStockSection /> <UploadSection /> <FooterActions /> </Form> ); }

每个子 Section 内部通过Form.useFormInstance()拿到父级的 form 实例。这是 antd 提供的跨组件共享表单实例的官方方案，不需要自己用 context 传递。但两个坑需要提前说明：一是不可以通过 prop 把 form 实例传给子组件，子组件必须放在 Form 组件的上下文里才能拿到；二是子组件里不要反挂一个initialValues，它只在表单首次挂载时生效，动态修改子组件的 props 不会更新表单值。如果字段值需要随外部变化，要用setFieldsValue，或者给表单设置key强制重挂载。

上传图片的组件我封装得很谨慎。中后台的上传通常需要先调后端拿上传凭证，再走第三方存储。我把这个流程封装进了UploadImage组件内部，对外只暴露value和onChange，这样业务层完全感知不到上传细节，表单提交时拿到的就是图片 URL 列表。

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

4.1 状态更新但视图不刷新

“rea”开发过程中，遇见过几次很典型的“数据变了，页面不更新”的问题。其中一次出现在列表页的编辑弹窗里，我在弹窗中修改了一行数据，关闭弹窗后列表没有刷新。排查发现业务代码里只改了本地 state，根本没有重新拉取接口数据。

这一类问题通常是三个原因：一是改的事件不对，更新的不是当前渲染的数据源；二是引用的数据源被 Copy 了，新对象已经脱离了旧引用链；三是在 useEffect 的依赖数组里漏了关键变量，导致回调持有的是旧闭包。排查技巧是先看 React DevTools 的组件树里 props 和 state 到底变了没有，如果变了但视图没变，大概率是引用问题；如果根本没变，多半是重复渲染被React.memo拦截了。

4.2 内存泄漏与 AbortController 使用

还有一个比较隐蔽的坑：在列表页频繁切换 Tab，或者快速输入查询关键词时，接口响应顺序错乱会导致页面展示的数据和最新筛选条件对不上。比如我先搜“苹果”，又改搜“香蕉”，但“苹果”的接口响应慢，后返回，表格就会被旧数据覆盖。

针对这个问题，我在封装的usePageData里加了请求竞态处理。本质上是用AbortController在发起新请求时取消旧请求：

useEffect(() => { const controller = new AbortController(); fetcher(params, { signal: controller.signal }) .then((result) => setData(result.list)) .finally(() => setLoading(false)); return () => controller.abort(); }, [params]);

这样旧请求要么被终止，要么即使返回了也不会被设置到 state 中。能有效避免竞态，同时还能在组件卸载时顺带清理请求。排查这种问题不要靠肉眼盯代码，建议把所有接口请求的发起时间、结束时间打成日志，对照时间线就很清楚了。

4.3 构建体积与首屏加载优化

“rea”项目的生产构建配置里做了一些必要的体积优化。antd 组件库必须按需引入，不能全量打包。在 Vite 中这需要用到unplugin-vue-components对应的 React 方案，或者直接手动引入组件和样式。我当时选择了手动方式，简洁可控，缺点是每次用新组件要记得加 import。为了保险，我在代码审查时加了一个 ESLint 插件去检查 antd 的 import 路径。

另一个关键是路由级代码分割。React 18 配合React.lazy+Suspense能把每个页面的代码拆成独立的 chunk，首屏只加载必要的部分。比如登录页的代码只有几 KB，完全不占用首屏的下载时间。

const OrderList = React.lazy(() => import('@/pages/OrderList/Index'));

这里要提醒一点：懒加载路由需要配合Suspense的 fallback，否则页面切换时会白屏。我在布局组件里加了全局的Spin页面级 loading，顺手解决了这个问题。

4.4 多环境配置管理

项目的接口地址和其他配置项在不同环境（开发、测试、生产）下不一致。Vite 提供了.env.development、.env.test、.env.production的环境变量文件机制。我在这里做了一个规范约定：所有环境变量统一以VITE_前缀开头，并且必须定义在类型声明文件里，这样在代码里使用import.meta.env.VITE_API_BASE_URL时，TypeScript 能给出提示和类型校验。

实际部署中，最常出问题的是“配置已改但线上没生效”。排查思路是先看import.meta.env.MODE是不是正确的环境标识，再看构建产物里搜索对应的字符串是否被正确替换。如果产物的值是空，多半是环境变量文件没被正确加载，比如文件名拼写错了。

5. 测试、构建与发布流水线

5.1 单元测试与组件测试策略

“rea”项目的测试策略没有追求全覆盖，而是聚焦在高价值的模块上。工具函数、公共组件、权限 hook、接口封装是测试重点，业务页面则以关键逻辑验证为主。测试框架选了 Vitest，和 Vite 无缝集成，速度非常快，配置也很简洁。

以权限 hook 为例：

import { renderHook } from '@testing-library/react'; import { usePermission } from '@/hooks'; describe('usePermission', () => { beforeEach(() => { useAuthStore.setState({ permissionCodes: ['user:manage'] }); }); it('返回 true 时表示有权限', () => { const { result } = renderHook(() => usePermission('user:manage')); expect(result.current).toBe(true); }); it('不存在的权限码返回 false', () => { const { result } = renderHook(() => usePermission('order:delete')); expect(result.current).toBe(false); }); });

组件测试最怕的是 DOM 细节变化导致用例频繁翻车。我的建议是尽量测试组件的行为和输出，而不是测试具体的 class 名称。比如一个按钮点击后调用的函数、弹窗出现时显示的文字，这些断言的稳定性远远高于检查某个 div 的 className。

5.2 ESLint 与 Prettier 集成

工程代码规范不只是摆设，它直接关系到团队协作的效率和代码的可维护性。在“rea”项目中，我把 ESLint 和 Prettier 做成了提交前强制校验。

package.json中这样配置：

{ "husky": { "hooks": { "pre-commit": "lint-staged" } }, "lint-staged": { "*.{ts,tsx}": ["eslint --fix", "prettier --write"] } }

需要注意的坑是 ESLint 和 Prettier 之间可能会产生规则冲突，比如 ESLint 要求单引号、Prettier 要求双引号。解决方式是使用eslint-config-prettier把 ESLint 的格式类规则全部关掉，格式问题交给 Prettier 处理，风格检查交给 ESLint 处理。职责分离，各管各的。

5.3 打包分析与持续部署

构建产物的体积直接关系到上线后的用户体验。我习惯在每次构建前跑一下rollup-plugin-visualizer生成依赖分析图。看到某个依赖特别大且业务价值有限，就考虑用动态 import 按需加载，或寻找替代方案。

“rea”项目的发布流程是：代码 push 到主干分支后，由 CI 自动触发安装依赖、执行 lint、跑测试、构建产物。通过后再由部署平台拉取产物发布到不同环境。整个流程中唯一需要人工参与的环节就是生产环境的发布确认，其他全部自动化。

一个值得啰嗦的细节是：构建机器的 Node 版本必须和开发环境保持一致。出现过好多次本地构建正常、CI 上构建失败的情况，最后定位到是 CI 机器的 Node 版本太旧，esbuild 不支持，换了版本立刻就好了。后来我在 CI 配置文件里显式指定了 Node 版本，这个问题就再也没出现过。

6. 性能调优与体验细节打磨

6.1 减少不必要的重渲染

React 应用性能问题的第一大来源就是无谓的重渲染。页面复杂度高了以后，父组件一点击某个按钮触发了 state 更新，整个页面的子组件全部跟着刷新，感官上就是“卡”。排查这类问题，我用 React DevTools 的 Profiler 录制一段交互，看哪些组件实际被重新渲染了。

优化的手段分三层：第一层是使用React.memo包裹那些 props 基本不会变化的子组件；第二层是让组件的 props 保持稳定，应用useCallback和useMemo，不要让父组件每次 render 都重新生成函数或对象；第三层是状态下沉，把和某个子树相关的 state 放到该子树内部去管理，不放在顶层。

这里有一个反直觉的经验：不要滥用useMemo。它本身有内存开销，只有计算量比较大或者引用必须稳定时才值得用。无脑给所有函数包useCallback，代码看着专业，实际收益不大，甚至可能因为依赖数组写错导致闭包陷阱。

6.2 大数据列表渲染优化

“rea”里有一个网格视图需要展示几百条带图片的卡片数据，直接map渲染会导致初次渲染卡顿、滚动掉帧。后来我引入了懒渲染的方案：只渲染可视区及缓冲区的卡片，而不是渲染全部数据。市面上有成熟的虚拟列表库，但为了控制体积和耦合度，我直接在列表容器上用 IntersectionObserver 实现了“加载更多”的方案。

这个方案的思路是：容器底部放一个哨兵节点，当哨兵节点进入可视区域时，加载下一页数据，追加到列表尾部。配合滚动容器本身的overflow: auto和max-height，实现在不引入复杂依赖的情况下流畅浏览大数据列表。实测下来，几百条数据完全没问题，如果数据量到了几千甚至上万，就该考虑完整的虚拟列表库了。

6.3 交互反馈与加载体验

中后台项目的用户体验经常被忽略，但它恰恰是区分“能用”和“好用”的分水岭。“rea”项目里，我把页面级的加载统一做了收敛：初次进入页面时显示骨架屏；刷新数据时表格区域显示覆盖式的 loading；提交表单时按钮变为加载态并禁止重复点击。

这些细节都不难实现，但对用户的主观体验提升非常明显。最怕的是点击一个按钮没有任何反馈，用户会以为页面没响应，然后连续点击，最后提交了一堆重复请求。所以“防重复点击”是我在代码评审里必查的一项。

7. 兼容性与工程化复盘

7.1 代码拆分与依赖升级策略

“rea”项目中期，团队决定升级了几个核心依赖的版本。升级 React 到 18 的工作量并不大，真正的麻烦在于升级 antd 带来的破坏性变更，以及部分旧组件库版本间的兼容问题。我做的第一件事是看官方迁移文档，把 breaking change 逐个列出来，再对照项目里的组件使用情况，列出受影响清单。升级过程中，先升级小版本，再把所有用例跑一遍，确认没有回归才继续升下一个版本。

这里我想强调一个团队协作上的经验：依赖升级要单独开分支，不能和业务功能混在同一个提交里。否则上线后一旦出问题，定位是变更导致的还是业务回归导致的，会浪费大量时间。

7.2 多个环境变量与部署注意事项

生产环境部署时，最容易踩的坑就是用了开发环境的接口地址，导致线上的页面请求打到测试环境去了。排查这个问题时，建议先确认产物里的环境变量确实被替换成了目标值。如果用的是 CI 部署，检查 CI 脚本里build命令执行时的MODE参数。

“rea”项目在后来的部署中加了一步校验：构建完成后，扫描产物目录里是否存在开发环境的域名串，存在就终止发布。虽然做法比较粗暴，但确实有效，避免了人为失误导致的环境串场事故。

7.3 后续演进思路

项目的工程骨架搭好之后，后续的演进方向可以围绕两点展开：一是把接口层进一步抽象成代码生成器，后端更新接口文档后前端自动生成对应的类型定义和请求函数，减少手工维护的成本；二是引入更细粒度的权限模型，把权限控制的粒度从页面、按钮进一步下沉到数据行和数据列。

在“rea”项目里，我目前采用的是基础的角色权限模型。如果业务量继续增大，多租户、多组织的复杂权限需求出现，可以基于现有usePermission机制平滑扩展，不会推翻重写。这也是当初没有引入重型权限框架的原因——很多框架面对复杂业务反而成了约束。

从我个人的体会来说，中后台项目的重构最忌讳一上来就追求“完美架构”。好的架构不是设计出来的，是在业务迭代中慢慢打磨出来的。“rea”这个项目的骨架只抓手了几个核心原则：分层清晰、边界明确、命名规范、配置集中，剩下的细节都是水到渠成的事。

最后再分享一个小技巧：项目里一定要维护一份简短的 README，写清楚“命令怎么跑、目录怎么分、特殊约定有哪些”。不需要多详尽，几百字就够，但能救下三个月后接手的新人的命。我这回就吃过没读文档的亏，有一段时间被代码里的“历史包袱”弄得焦头烂额，后来花了一个下午把各种约定补齐写进文档，整个团队的工作效率都上了一个台阶。