Umi v3 是一套偏企业级、中后台导向的 React 应用框架。它解决的核心问题不是“如何写一个组件”，而是“如何把一个复杂后台系统组织起来”。

Umi v3 的定位

适合这类项目：

• 中后台管理系统
• 权限、菜单、布局规则较重
• 需要约定式路由和统一工程体系
• 与 Ant Design / dva 生态结合紧密

核心能力

• 约定式与配置式路由
• 布局组织
• 插件化扩展
• 权限控制
• 与 dva、Ant Design、mock 工具协作

路由组织

Umi 的路由能力可以从两个角度理解：

• 约定路由：目录结构映射页面结构
• 配置路由：显式定义页面、嵌套、权限、重定向

对于中后台项目，配置式路由通常更适合：

• 更容易统一做权限
• 更容易接动态菜单
• 更容易表达布局边界

权限与包装器

Umi 常见做法是通过路由包装器处理认证与鉴权。思路上与 React Router 的受保护路由一致，只是框架把接入点做得更统一。

实践里通常会区分三层：

• 页面访问权限
• 菜单可见性权限
• 接口级权限校验

与 Ant Design / dva 的关系

在很多历史项目里：

• Umi 负责工程骨架和路由
• Ant Design 负责 UI 体系
• dva 负责状态和副作用

这套组合的价值在于团队协作成本低、上手路径清晰、约定统一。

学习 Umi v3 时要关注什么

• 路由和布局如何组织
• 权限模型如何接入
• 插件机制解决了什么问题
• 约定优于配置的边界在哪里

版本视角

这个页面保留 v3 视角，是因为很多企业项目仍然能遇到它。阅读时要有版本意识：

• 学的是“企业级 React 应用如何组织”
• 不只是背 Umi 某个版本的命令和配置项

实践建议

• 新项目先判断团队是否真的需要 Umi 这类强约定框架
• 老项目维护则优先吃透路由、权限、布局三条主线
• 把框架能力和业务约束分开理解，迁移时才不会被工具绑死

贡献者: Ra1n, Qwen-Coder

上一页Next.js

下一页组件化开发