如果说 4+1 视图模型 是架构设计的**"思想框架" （我们要画哪几张图），那么 UML (Unified Modeling Language) 就是架构设计的"通用语言"**（这几张图具体怎么画）。
很多前端开发者听到 UML 会觉得那是后端写 Java 的人才用的东西。其实不然。
前端架构师如果不掌握 UML，就像建筑师只会口述"这里有个柱子"，却画不出精确的图纸。
"UML 不是教条，而是让你的设计文档能被全球程序员读懂的 Esperanto（世界语）。"
graph TD
A[UML图分类] --> B[结构图]
A --> C[行为图]
B --> B1[类图]
B --> B2[对象图]
B --> B3[组件图]
B --> B4[部署图]
B --> B5[包图]
C --> C1[用例图]
C --> C2[活动图]
C --> C3[状态机图]
C --> C4[交互图]
C4 --> C4a[时序图]
C4 --> C4b[协作图]
C4 --> C4c[交互概览图]
C4 --> C4d[时序图]
我将挑选最适合前端架构的 5 种 UML 图，并结合 Mermaid 代码进行演示。
1. 为什么前端需要 UML？
在没有 UML 的时候，我们画图通常是"随意发挥"：圆圈代表组件，方块代表数据库，箭头代表请求。但新来的同事看不懂：这个箭头是数据流向，还是依赖关系？
UML 解决了歧义性。它规定：
- 实线箭头 → 是关联。
- 虚线箭头 ⇢ 是依赖。
- 空心菱形 ⋄ 是聚合。
掌握 UML，就是掌握了技术设计的标准表达能力。
2. 前端架构师必须掌握的 5 种 UML 图
我们将它们映射回 4+1 视图，让你的知识体系闭环。
① 用例图 (Use Case Diagram)
- 对应视图：场景视图 (Scenarios)
- 前端视角 ：谁（Actor） 在这个页面上能 做什么（Use Case） ？
- 作用：界定系统边界。比如，"普通用户"只能浏览，"管理员"可以删除。
graph LR
%% 这是一个简化的用例图风格
User((C端用户))
Admin((管理员))
subgraph System [电商前台系统]
direction TB
UC1(浏览商品)
UC2(加入购物车)
UC3(后台下架商品)
end
User --> UC1
User --> UC2
Admin --> UC3
② 类图 (Class Diagram)
- 对应视图：逻辑视图 (Logical)
- 前端视角 ：数据模型 (Interfaces/Entities) 和 组件关系。
- 作用：描述 TypeScript 接口定义、React/Vue 组件的 Props 继承关系。这是重构时最有用的图。
classDiagram
%% 定义接口
class User {
+String id
+String name
+login()
}
class Cart {
+List~Item~ items
+calcTotal()
}
class Product {
+String sku
+Number price
}
%% 关系描述
User "1" --> "1" Cart : 拥有 >
Cart "1" o-- "*" Product : 包含 >
③ 时序图 (Sequence Diagram) ------ 最重要的图
- 对应视图：处理视图 (Process)
- 前端视角 ：组件、BFF、后端服务之间的交互顺序。
- 作用：理清异步流程。比如 OAuth2 登录流程、支付回调流程。前端最容易出 Bug 的地方都在时序上。
sequenceDiagram
participant User as 用户
participant UI as 前端页面
participant BFF as BFF层(Node)
participant Auth as 认证服务
User->>UI: 点击登录
UI->>BFF: POST /api/login
BFF->>Auth: 验证账号密码
Auth-->>BFF: 返回 Token
BFF-->>UI: Set-Cookie: Token
UI-->>User: 跳转至首页
④ 状态图 (State Diagram)
- 对应视图：处理视图 (Process)
- 前端视角 ：复杂 UI 的状态流转。
- 作用：描述一个对象（如"订单"、"播放器"、"表单"）生命周期内的所有状态。比如订单从"待支付"到"已发货"的各种变迁条件。
stateDiagram-v2
[*] --> Idle: 页面加载
Idle --> Loading: 用户点击搜索
Loading --> Success: 接口返回 200
Loading --> Error: 接口返回 500
Success --> Idle: 重新搜索
Error --> Loading: 点击重试
⑤ 部署图 (Deployment Diagram)
- 对应视图：物理视图 (Physical)
- 前端视角 ：代码构建后去哪了？
- 作用：展示 CDN、Nginx、容器、客户端环境的拓扑结构。
graph TB
%% ================= 样式定义 =================
classDef plain fill:#fff,stroke:#333,stroke-width:1px;
classDef server fill:#e1f5fe,stroke:#0277bd,stroke-width:2px;
subgraph Client ["用户终端 (Client)"]
direction TB
Browser["Chrome/Safari"]:::plain
App["App WebView"]:::plain
end
subgraph Network ["网络层 (Network)"]
direction TB
CDN(("CDN 加速")):::plain
LB["Nginx 负载均衡"]:::plain
end
subgraph Server ["服务端容器 (Server)"]
direction TB
%% 修复点：这里必须加双引号 "..." 否则报错
Node["SSR 服务 (Pod)"]:::server
API["后端 API (Pod)"]:::server
end
%% 连接关系
Browser --> CDN
App --> CDN
CDN --> LB
LB --> Node
Node --> API
3. 工具推荐 (Tooling)
作为架构师，工具的选择体现了效率。
-
Mermaid (强烈推荐)
- 特点：代码即图表 (Diagram as Code)。
- 场景：直接写在 Markdown 文档、Notion 或掘金文章里。利于版本控制（Git Diff 能看出图改了哪里）。
-
PlantUML
- 特点：功能最强大，支持最标准的 UML 规范。
- 场景：非常复杂的后端架构设计。
-
Draw.io / Excalidraw
- 特点：拖拽式，手绘风。
- 场景：头脑风暴，PPT 展示（Excalidraw 的手绘风非常适合技术分享）。
-
随意发挥
- 现在有很多AI工作流的绘图网站
4. 观点建议
- UML 不是为了画给别人看，而是为了帮自己想清楚。很多时候图画不出来，说明逻辑没理顺。
- 前端不要过度设计 。不需要把每一个函数都画进类图里，只画核心领域模型 和关键交互链路。
- 图文不符是灾难。如果代码改了，图必须更新。这就是为什么推荐 Mermaid（代码化）的原因。