复合脑图:全元素混搭
3.3.1 一张图里装下前两章的一切
前面两章讲的元素——富文本、链接、图片、公式、复选框、代码块、表格——可以全部出现在同一张图里。混合的关键是记住每个元素在树上的「身份」:
| 元素 | 在树上的身份 | 适合挂的层级 |
|---|---|---|
| 标题 | 骨架分支 | 一到三层 |
| 列表项 | 血肉节点 | 任意层 |
| 富文本 | 任意节点的「皮肤」 | 不占层级 |
| 公式 | 细节节点 | 三层以后 |
| 复选框 | 任务节点 | 执行类分支下 |
| 代码块/表格 | 宽节点 | 二三层 |
| 链接/图片 | 入口节点 | 二三层 |
来一张真正的复合图——一份「课程设计说明书」式的图:
# 毕业设计:图书管理系统
- **选题背景**
- 校内图书流通量年增 `40%`
- 现有系统老旧,==2020 年后未更新==
- **技术方案**
- 后端:Spring Boot
- 前端:Vue 3
- 数据库核心表
| 表名 | 说明 |
|---|---|
| book | 图书信息 |
| borrow | 借阅记录 |
| user | 读者账户 |
- **核心接口**
```bash
GET /api/books?keyword=
POST /api/borrow
PUT /api/return/{id}
```
- **进度**
- [x] 开题报告
- [ ] 数据库建模(本周)
- [ ] 接口联调
- **参考**
- [Spring Boot 官方文档](https://spring.io/projects/spring-boot)
—— 渲染效果 ——
# 毕业设计:图书管理系统
- **选题背景**
- 校内图书流通量年增 `40%`
- 现有系统老旧,==2020 年后未更新==
- **技术方案**
- 后端:Spring Boot
- 前端:Vue 3
- 数据库核心表
| 表名 | 说明 |
|---|---|
| book | 图书信息 |
| borrow | 借阅记录 |
| user | 读者账户 |
- **核心接口**
```bash
GET /api/books?keyword=
POST /api/borrow
PUT /api/return/{id}
```
- **进度**
- [x] 开题报告
- [ ] 数据库建模(本周)
- [ ] 接口联调
- **参考**
- [Spring Boot 官方文档](https://spring.io/projects/spring-boot)
这张图里六个分支六种材质:文字、数据、表格、代码、任务、链接——但骨架依然是干净的五根树枝。
3.3.2 混搭的两条军规
军规一:骨架归标题,细节归列表。 混搭最容易犯的错是「什么都往标题上写」,比如 ## **技术方案**(含表格与代码)——标题是分类不是内容,花样全部交给节点去做。
军规二:宽节点独占一个位置,不要并列堆叠。 表格、代码块这类宽节点如果连着放好几个,那一段画面会全被撑满。让宽节点之间隔着窄节点(几个列表项),图面的疏密就有节奏了。
3.3.3 一个检验复合图质量的土办法
写完复合图,做个「折叠测试」:把三、四层全部折起来,只看第一、二层——
- 如果只看骨架就能复述出整图大意(「选题背景、技术方案、核心接口、进度、参考」),骨架合格;
- 如果骨架上看不出某分支是干什么的(比如第二层只有「其他」两个字),说明关键信息放得太深,要往上提。
复合图是花式用法的集大成,但元素越多越要克制——每加一种元素前问一句:这个信息是「结构」还是「细节」? 结构用标题,细节才用花式。
下一篇解决复合图的天然副作用——图大了怎么办:分组、瘦身与防卡顿(见 《大图收纳术》)。
