业务模块地图

本文面向准备评估、复用或改造商业版前端模块的研发人员。它需要回答的问题是：

“用户看到的功能，在前端代码中分别落在哪些目录、路由和接口文件里？”

如果你已经准备开始改业务，这一页通常会比只看目录树更有帮助。

总体模块分布

当前前端业务主要可以按 9 组来理解：

模块组	主要目录	典型用途
仪表盘	src/views/dashboard	首页驾驶舱、分析看板、业务概览
系统管理	src/views/system	用户、角色、部门、菜单、参数、文件中心
监控中心	src/views/monitor	在线用户、服务器、缓存、安全审计
通知中心	src/views/system/notification	公告、通知、收件箱
调度中心	src/views/scheduler	定时任务与任务日志
工作流	src/views/workflow	流程分类、定义、实例、任务
内容管理	src/views/content	分类、标签、内容列表、详情、回收站
商城	src/views/mall	商品、分类、订单、详情和编辑页
模板页	src/views/template	卡片、图表、日历、聊天等演示素材

各模块的阅读建议

仪表盘

适合用来快速感受系统视觉和布局能力，但不建议把所有演示卡片直接当生产业务逻辑使用。更推荐把它当成首页定制的素材层。

系统管理

这是最接近后台基础能力的模块组，也是大多数业务项目中最先复用的一组能力。优先理解：

• 用户
• 角色
• 部门
• 菜单
• 参数
• 文件中心

监控中心

这组模块的价值不在于页面多复杂，而在于它和后端运维能力有直接对应关系。适合在实际项目中保留为运维入口。

工作流、内容、商城

这三组最适合判断商业版“能承接多深的业务场景”。如果你做的是企业门户、审批系统、电商后台，这几组很值得重点研究。

一个模块通常由哪些部分组成

大部分模块由多层内容共同组成：

router/modules      菜单与路由模板
views/<module>      页面实现
api/*               接口封装
types/*             类型声明（按需）
store/hooks         复杂状态或复用逻辑（按需）

推荐的理解方式

想了解模块做了什么

先看：

1. src/router/modules/*.ts
2. src/views/<module>

想确认模块联调方式

再看：

1. src/api
2. 对应页面里调用了哪些接口

想评估模块扩展方式

最后再看：

1. 是否有通用组件支撑
2. 是否有独立 hooks
3. 是否已经预留按钮权限

推荐优先理解的模块

不是所有模块都需要相同的阅读优先级。通常最值得先理解的是：

• 系统管理
• 文件中心
• 通知中心
• 监控中心
• 工作流

这些模块更接近平台能力，通常比单个演示页面更适合在业务项目中保留。

适合作为改造素材的模块

• 仪表盘
• 模板页
• 部分内容和商城页面

这类模块更适合作为快速出效果的基础，再根据业务需求继续改造。

检查清单

评估模块复用范围时，建议确认：

• 当前项目需要的功能是否已有对应 views、api 和 router/modules 实现。
• 直接复用的模块是否已完成菜单、权限和后端接口联调。
• 需要项目定制的模块是否已经明确保留、改造或移除边界。